Speaking as a Tummy.com customer, I have a virtualized linux server. My processes are isolated from Tummy's other clients on that piece of hardware at the OS level. I still face the same issues with long-running processes, but at least it is all from code that I maintain on a server image that I manage. If I had competing processes that were hard to reconcile, I'd probably just get another virtual server from Tummy.
On Sun, 2005-03-27 at 17:49, 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? -- Lloyd Kvam Venix Corp _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
