2008/8/28 Ian Bicking <[EMAIL PROTECTED]>: > > Ben Bangert wrote: >> On Aug 14, 2008, at 6:23 PM, Cliff Wells wrote: >> >>> Possible replacement for Paste#http: >>> >>> http://pypi.python.org/pypi/Spawning/0.7 >>> >>> A speed comparison of Django+mod_wsgi vs Spawning that lacks enough info >>> to be labeled definitive, but interesting nonetheless: >>> >>> http://www.eflorenzano.com/blog/post/spawning-django/ >>> >>> My own tests have been limited to changing a fresh Pylons project's >>> test.ini to use egg:Spawning rather than egg:Paste#http and verifying >>> that Pylons runs, so YMMV ;-) >> >> I've gotten similar results to the benchmark there for a Pylons app. >> Though there's a few things Paste#http does that neither >> PasteScript#cherrypy (faster than Paste#http), nor spawning do. Might >> help to illustrate the differences: >> >> Paste#http >> - Uses thread-pool >> - Can launch additional threads in the event threads are all taken >> - Can kill 'stuck' threads to avoid server stall >> - Can recycle threads after configurable amount of requests (helps with >> possible memory leaks) > > At least potentially Spawning should be able to do all of these, but > using subprocesses instead (probably with greater reliability). > mod_wsgi already does this, in effect, using the Apache process > management. > > I believe, but I'm not sure, that Spawning reads the entire input > (asynchronously) before calling the WSGI application, which would also > allow it to support many more incoming uploads. Generally it has at > least the potential to more gracefully handle lots of nasty overload cases. > > Also, if you don't use subprocesses or threads with it, you can run your > WSGI application asynchronously. This won't work if you use databases > or even files, but for some applications it might provide interesting > possibilities -- specifically lots of concurrent requests, or things > like Comet-style applications that push events. > The quid of the question is where are the threads or process: http://wiki.secondlife.com/wiki/Eventlet/Documentation#Integrating_Blocking_Code_with_Threads http://twistedmatrix.com/documents/current/api/twisted.internet.threads.html#deferToThread
Expose a event server to client sound great. The next step is more fuzzy: * Event load balancer (ej: nginx) -> Normal threaded or process server * Event server -> Non-blocking wsgi with a lot of tricks Thinking in third party wsgi, the second one is dangerous. Thinking to share resources between calls sounds clever. Excuse my poor english. Regards, Javi --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
