[Web-SIG] A query for hosting providers
mike_mp at zzzcomputing.com
Mon Mar 28 02:54:24 CEST 2005
if you run multiple virtual hosts out of Apache, mod_python by default
creates new subinterpreters, via Py_NewInterpreter, for each virtual
host. this can also be set up per apache directive, an arbitrary name,
or within individual directories.
although how well Py_NewInterpreter separates each interpreter from
each other, I am less certain of....though Im sure a particular
subinterpreter would have to have a pretty catastrophic failure (i.e.
segfault or similar) to affect the parent and/or siblings.
I am running multiple interpreters myself but it hasnt been heavily
On Mar 27, 2005, at 5:49 PM, Ian Bicking wrote:
> I'm wondering -- and this is mostly directed to the hosting providers
> (Remi, Sean...) -- what are the problems with providing
> commodity-level hosting for Python programs? I can think of some, but
> I'm curious what you've encountered and if you have ideas about how to
> improve things.
> Some things I've thought about:
> * Long running processes are hard to maintain (assuming we rule out
> CGI). Code becomes stale, maybe the server process gets in a bad
> state. Sometimes processes becomes wedged. With mod_python this can
> effect the entire site.
> * Isolating clients from each other can be difficult. For mod_python
> I'm assuming each client needs their own Apache server. Maybe this
> isn't as much of a problem these days, as virtualizing technologies
> have improved, and multiple Apache processes isn't that big of a deal.
> * Setup of frameworks is all over the place. Setting up multiple
> frameworks might be even more difficult. Some of them may depend on
> mod_rewrite. Server processes are all over the place as well.
> But I don't have a real feeling for how to solve these, and I'm sure
> there's things I'm not thinking about. How do you guys do it now, and
> if you could change this stuff -- on any level, from interpreter to
> framework -- what would you do?
> Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
More information about the Web-SIG