A take on Tornado and "modern" web servers

He seems to recognize (correctly) that Apache's mpm idiom is crap, but he still seems to think that its model of loading multiple language runtimes into one monolithic process is a good idea.<p>Why does it matter if you use 4 or 8 event-handling processes on one machine, each with their own database connection? If that's your scaling bottleneck, you'd be running on many machines anyway, so a small constant multiplier doesn't change the story. Besides, you could use crap like ODBC to have one persistent DB connection per machine.

... or you could use Erlang and it takes care of a lot of that crap for you.<p>That said, I think the big pain point is really the data store in any case. Yeah, it's nice to handle more with less, but in the end, adding django/rails/php/whatever machines is easy and a known quantity. It's tougher to scale up the data store.

Copying my comment from my comment page.<p>Well like I mentioned I believe that is an implementation detail. For example, if you have the subprocess you have two fundamental designs. The first being where the master process still manages the client socket (so data is transfered from the worker back to the master). The second being where you pass the client socket (over a UNIX message with send_msg) and allow the worker to flush the buffers and close the socket. The problem with the first is that you increase the amount of wake-ups your event loop needs to do by 2x (since it needs to handle data in and out for the worker) which could increase your handling latency. This is a no-go in some applications. The problem with the second model is you lose the ability to have connections live longer their request (otherwise they are restricted to that workers affinity which will not be evenly balanced).<p>ODBC is an option (or SQL Relay) but it adds an increased latency without providing the ability to yield on the resource being ready. For example, even with the models I described above to reduce over subscription of resources, your container may not be correct in its assumption that the connection has little contention. So you effectively add latency and reduce correctness in your ability to run efficiently.

I'm surprised there has been no discussion around NT's IO Completion Ports on this topic. IOCPs have this magic where the scheduler makes sure the number of threads running from a worker pool are the optimum for the number of cores on the system. It lends itself well to writing hi-perf networking apps where you're waiting on a bunch of objects using MsgWaitForMultiple or some equivalent.

Sorry to kungfudoi for posting this half an hour after he/she posted it:<p><a href="http://news.ycombinator.com/item?id=820962" rel="nofollow">http://news.ycombinator.com/item?id=820962</a>