[Chicago] Status of wsgi

[Jordan Bettis]

On 10/11/2012 01:25 PM, Carl Karsten wrote:
> On Wed, Oct 10, 2012 at 11:14 PM, Jordan Bettis <jordanb at hafd.org> wrote:
>> But if there's no mechanism for setting the request aside, the the
>> worker thread has to sit around doing nothing while the search server
>> does its thing. An asynchronous framework would let the worker set the
>> request aside and process new requests while it's waiting for the
>> response from the search server.
> 
> What is the difference between "sit around doing nothing" and "setting
> the request aside"  ?
> 
> I am guessing there is a resource (memory, connections, stack?) issue,
> but I don't really see how either model is going to be much different,
> so I must be missing something.
> 

The assumption is that the application is setup as fixed pool of
workers. A worker waiting for a third party response is one that can't
process any more requests. Since sites with this configuration typically
have about as many workers as they have cores, the number of workers per
server is going to be on the order of dozens, and tying one up
represents a serious waste.

Of course you can have a dynamic worker pool. That's the way apache
works. Given that python has a fairly "big boned" runtime, there's a
substantial cost there, as well as doing other things like making DB
connections for the new workers. And anyway it still only partially
solves the problem. You're still going to run out of memory or file
descriptors or something eventually. Compare Apache's behavior in the
face of a Slow DOS attack compared to that of an asynchronous server
like nginx.