[Web-SIG] Re: Preferred set of WSGI servers

[Ian Bicking]

Jacob Smullyan wrote:
> On Fri, Apr 29, 2005 at 11:53:30AM -0500, Ian Bicking wrote:
> 
>>I can imagine a good setup for hosts being one based on forking per-user 
>>processes, which is adaptive primarily to scale down -- e.g., a largely 
>>dorman app could have 1 or even 0 processes running (at 0 it becomes 
>>similar to CGI, but presumably the process would stay around for some 
>>time to respond to subsequent requests).  The "scaling down" scenario I 
>>often think about would be a email contact form -- one of those things 
>>that has to be an app, can be implemented and deployed separately from 
>>other aspects of the site, and yet it's clear waste of resources to keep 
>>a process always around to respond to such requests.  Though it's 
>>actually someplace where CGI would work just fine; but lets say you 
>>don't want to educate the developer about when they might want to use 
>>other deployment strategies (which is a rather complex discussion 
>>really, that would be better avoided by providing one really good 
>>strategy and telling everyone to use it).
> 
> 
> Why prefer forking to threads in this case?

Threading doesn't provide much isolation, so it's not really feasible 
for a multiuser situation.  Well, Zope 2 managed it, but only with 
signficant heroics that also degrade the programming experience.

OTOH, I don't know if it's useful to optimize for situations where most 
of the website is static with small dynamic portions.  In a practical 
sense dynamicism (of some sort) is almost the norm these days (at least 
if a programmer is involved).  So one threaded process per client may be 
reasonable as well.

One of mod_webkit's underutilized features was the ability to drop .psp 
files anywhere, and have them processed in a single process.  This is 
also possible with other configuration techniques (rewrite rules, 
LocationMatch, etc), but not popularized in other frameworks either. 
Probably in part because of the module/package orientation of Python, 
and it's less comfortable to be loading files from arbitrary locations. 
  Explicit relative imports would be a real boon in this situation.

Oh, and that brings up another point -- separate processes mean separate 
sys.paths and other isolation.  Managing sys.path is a total pain in the 
butt.  And module reloads of course, but even ignoring that sys.path is 
still annoying.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org