Web, scripting languages & performance [Was: FlowerScirpt teaser]

[kenny]

Vladimir Panteleev wrote:
> On Wed, 26 Sep 2007 13:11:00 +0300, Henning Hasemann <hhasemann at web.de> wrote:
> 
>> I would love such a framework. I'm also wondering if there might be a
>> way to avoid that awful stateless coding style, ie to be able to do
>> something like:
>>
>> ----
>> ask_for_users_address();
>> // user gets a form to enter its address, program here is "frozen" here
>> // until the user submits or the session times out
>>
>> ask_for_users_bank_account();
>> // present another form
>> ----
> 
> It should be possible with threads or fibers. Threads consume OS resources, so they may not be the perfect choice (consider the DoS attack scenario). If you don't allocate too much resources per thread/fiber (stack space, but not much is necessary here - just enough to control the state of a session), it might even be practically useable with some tuning.
> 

This is extremely difficult to do. The simple answer is, it's difficult to ensure that the user will get the same server in the second request. Also, if that server fails, what happens? I suppose the data for the address is lost, however that's not what you want. Machines fail. Also, if you MUST have the machine online, then you can't ever take the machine offline to do upgrades, reconfiguration or whatever. Take the example of google. They expect machines to fail, and implement failover in the software that they write -- bigtable and such.

I have written web frameworks in D -- with MVC and stuff, and it's very fast. It's not a scripting language, because all of the data work is done inside of D objects. IMO, it'd just be another MVC framework, until I write the portion that allows for automatic failover, distributed processing, and ways to implement intelligent caching and concurrency.

For example. I work for a web page that generates millions of page views a day. We run php, mysql, memcache. We have 4 php servers, and 8 DB servers. During peak, our php servers easily have a concurrency of over 100 processes simultaneously -- yet only 4% CPU usage. However, our DB servers have about 30 thread concurrency and about 600% CPU usage. (8 core machines).

We will never ever optimize php, because it spends only about 10-40ms inside of php and the rest at memcache and the DB servers. You can optimize D all you want, or even run your website in a C daemon, but most websites struggle because they have database problems.. Data grows exponentially, even with linear user growth, and becomes a huge problem, beacuse the database will grow larger than the memory of the machine, and can never distribute the query among multiple machines.

Personally, a D implementation of web specific distributed computing such as a bigtable implementation would be a whole lot more effective, and would actually begin to achieve the desire of the stateless computing better than threads or fibers ever could.

Just my 2 cents

Kenny