On 20/07/2013 14:02, Curtis Maloney wrote:
I'm more or less building atop flup as it is, however I plan to shed
anything not related to FastCGI.
For me it's a chance to get down and dirty with raw protocols again... I
do agree there is a shorter path to just applying Django's "fixes" to a
fork of flup.
--
Curtis
If you really want to get down and dirty with raw protocols have you
considered an implementation that used epoll or kqueue for the
networking? Combined with nginx as the front end HTTP server it should
(theoretically) result in a huge increase in performance.
Basing the work on one of the Python async networking libraries
(Twisted, Eventlet, gevent etc) should result in better performance and
might well make FastCGI competitive with uWSGI and WSGI again. I really
think that flup is the bottleneck when it comes to using FastCGI with
Django. Having said that I haven't had a chance to look at the Django
side of the code yet so there might be some optimisations that are
possible there as well.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
