[Chicago] Status of wsgi

Kumar McMillan kumar.mcmillan at gmail.com
Thu Oct 11 21:13:27 CEST 2012

Hi Garrett.
I'd say the best thing would be to take inspiration from how WSGI allows
disparate apps + middleware to interoperate without having to keep track of
each other's internal logic. It is an elegant API where you have a request,
response headers, a response I/O stream, and that's pretty much it. You
might be able to translate that into Erlang receiver patterns (or whatever)
to make it fit better with Erlang. When it was translated to Ruby as Rack (
http://rack.github.com/) I thought they did a good job of simplifying the
interface even further. A lot of that went into WSGI 2 so be sure to read
up on that one too.


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.
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20121011/11659b98/attachment.html>

More information about the Chicago mailing list