[Chicago] Status of wsgi

[Garrett Smith]

On Wed, Oct 10, 2012 at 11:52 PM, Tal Liron <tal.liron at threecrickets.com> wrote:
> I'll point out two possibly obvious things:
>
> 1. Most of what we consider "web" is indeed really "synchronous," in that
> there is likely a thread doing something (quickly if you want to scale!) and
> then sends us a response. But, there's nothing in particular that says that
> an asynchronous server can't handle that at the low level. Indeed, plenty of
> people build traditional web servers over asynchronous servers such as
> Tornado, Node.js or Jetty. I maintain that they often are doing so for the
> wrong reasons: asynchronicity does not guarantee graceful deterioration,
> especially if you (most likely) have a thread pool on top actually
> generating the content. (And, actually, many of the web servers that perform
> best under load are "synchronous" servers. They're just very smart about
> handling load, duh.) As a side note, there are implementations of HTTP/1.1
> chunking that create better throughput via some asynchronicity at the server
> level. As far as I know, this is not part of the WSGi spec, but some
> implementations may cache entities and chunk them... although, I would be
> surprised if any Python WSGi server does that. Would love to hear otherwise!

Yah, excellent point. This is sort of what I was getting at with the
question -- I've seen WSGI work very well for vanilla HTTP, but there
are bits of the HTTP protocol I haven't had a lot of experience with
(implementing chunking, e.g.) and I have no idea WTF web sockets are
:)

> 2. Actually, the Comet protocol for AJAX is truly asynchronous, in that a
> connection from the client is opened and stays open. They are not typical
> client-server requests by any means: if each of these connections held a
> thread on the server, you can forget about scalability. They are also not
> very typical AJAX, but some people like them. Again, not something that WSGi
> can help you with.

I'll need to dig some more to see how various WSGI compliant servers
handle this -- from what I've seen it involves cleverness with environ
and callback/coroutine aware helpers.

In a strict functional model, this could be handled using callbacks
(or monad like things), at the expense of sequential coherency.

> -Tal
>
>
> On 10/10/2012 11:14 PM, Jordan Bettis wrote:
>
> On 10/10/2012 08:48 PM, JS Irick wrote:
>
> Good evening Jordan-
>
> Can you explain what you mean by "doesn't support async"?  Asynchronous
> processes, asynchronous JavaScript, or something else?  I have pretty strong
> memories of using Ajax regularly from within django. (Basically using
> templates to build simple Json web services).
>
> I mean asynchronous server responses. Which is to say, a server receives
> a request, processes it for a time, makes a request on some other
> service, and then sets the request aside, to handle other requests.
> Later, when that other service returns its response, the server finishes
> processing that request and returns it to the client.
>
> Suppose you have a site which has a text search function. Your website
> is a 'standard' webapp which has a number of worker threads which
> receive requests, and process them into responses. But because search
> takes so much time, that's separated out into a dedicated process. When
> a worker receives a search request, it passes it on to the search server.
>
> 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.
>
> This is irrelevant to ajax because ajax is about client-side
> asynchronous requests. From the view of the server, each ajax call is a
> typical request-response synchronous cycle.
>
> WSGI doesn't support setting a request aside and processing others. When
> a request is made on a worker through WSGI, the worker is expected to
> generate a response *before* starting work on another request.
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>