On Sep 15, 3:25 am, Mike Malone <[email protected]> wrote:
> > I just checked in change to Tornado that enables you to run any WSGI-
> > compatible framework on Tornado's HTTP server so that Django apps
> > could run on top of Tornado's HTTP server and benefit from some of the
> > performance work we have done. (I just sent a message to django-users@
> > with getting started instructions as well, but if you are interested,
> > take a look
> > athttp://github.com/facebook/tornado/blob/master/tornado/wsgi.py#L188).
>
> Great news, there was a lot of discussion at DjangoCon last week after
> the Tornado launch about this possibility. There was a bit of hacking
> on it during the Django sprints, but things seemed to stall as people
> realized there were a few incompatibilities due to Tornado munging
> some of the HTTP headers (not sure the details, as I wasn't working on
> this stuff personally). Awesome to hear you made it work!
>
> > I chose the WSGI approach because it is generic and applies to all
> > frameworks, but Django is obviously the most widely used. I am curious
> > if there is any benefit to implementing more "native" support in
> > django.core.handlers or if WSGI is the preferred way of adding support
> > for new servers. If there is any performance or usability benefit, let
> > me know, because we would be happy to contribute our time to make it
> > happen.
>
> It would be interesting if you could formalize your issues with WSGI
> (it's not a horrible solution, but there are certainly places where it
> could be improved). Armin Ronacher was talking about updating the WSGI
> PEP at DjangoCon and was soliciting ideas, so you may want to get in
> touch with him and offer some suggestions for making WSGI work with
> high performance containers like Tornado.
Please, no async support in WSGI. It is not a good match. Even running
WSGI in a thread pool on top of async is a bad idea for a multiprocess
web server because you can't prevent the process accepting more
requests than the WSGI application can handle via the thread pool at
any one time. End result is that you can unnecessarily block requests
in one process which could otherwise have been handled by another
process which has available resources to handle them. WSGI on top of
non async multiprocess servers like Apache don't have this issue as
Apache will only accept connections when it knows that it has
available threads to handle the request.
Part of the reason that any update to WSGI specification has not come
out, is because the async crowd has derailed the discussion a couple
of times. The core people around WSGI do not believe that async
support should be a part of it, so please, if you want a standardised
async interface, do it independently.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
