Re: Solving mod_perl scalability issues for lots of slow connections

[Bob Ippolito]

On Dec 21, 2005, at 1:26 PM, Jonathan wrote: On Dec 21, 2005, at 12:23 PM, Perrin Harkins wrote: On Tue, 2005-12-20 at 14:42 -0800, Ken Simpson wrote: Alas, if only the Perl interpreter was truly thread safe and did not clone a new interpreter for each thread, we could just use threads... Those Python people have it good in some ways. Not that good really.  As I understand it, the Python interpreter has a global lock when using threads.  That's probably part of the reason why the most popular server framework for Python, Twisted, is single- threaded. I fwd'd this to a friend with commit access to twisted.  hopefully i'll get a response on clarification. But from what I understand, the Twisted networking framework works like this: The twisted 'reactor' is single threaded.  It uses select by default, you can use poll.  The docs suggest that one can specify a multithreaded reactor, but I'm not quite sure. The docs also specify a threadpool, and it seems that the deferred callback system has been implemented into it. CherryPy is a http server framework for python, and that supports a single or multi threaded server mode. Twisted does all network I/O multiplexed in one thread by way of something like select, poll, epoll, kqueue, WaitForMultipleEvents, or whatever other model is implemented by that reactor.  You can use as many other threads as you want for doing whatever else you want, but if you will get callbacks on the reactor thread and you must register callbacks on the reactor thread.  This model has been shown to scale extremely well (in any language). Python's GIL gets released by most code that does a lot of work or waits on a resource in C.  This means that when you're doing select(), a database call, etc. other threads get a chance to run.  Python bytecode runs in separate OS threads, but the GIL causes them to run round-robin.  This does two things: it makes it relatively easy to write threaded programs in Python, and it saves on memory as you only need a threadstate data structure per thread, not a whole interpreter. Interpreter-per-processor is of course the most scalable model in either language, because then you can run bytecode in parallel.  It's most portable and probably easiest to do this in separate processes rather than threads, especially considering that the multiprocess model can be made to scale across machines too. I don't think any of this is really relevant to mod_perl though, it's bound to the way Apache works. -bob