[Chicago] Status of wsgi

[Carl Karsten]

On Thu, Oct 11, 2012 at 1:59 PM, Jordan Bettis <jordanb at hafd.org> wrote:
> 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.
>

Oh right, I didn't consider the foot print of what is handling the
request/job.   I was just thinking of the network connection and some
how the server would magically... and there lies my problem :)



-- 
Carl K