[Web-SIG] A query for hosting providers

Remi Delon remi at cherrypy.org
Tue Mar 29 11:43:55 CEST 2005


> 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.

Yes, maintaining long-running processes can be a pain, but that's not 
related to python itself, it's true regardless of the language that was 
used to write the program.

> * Isolating clients from each other can be difficult.  For mod_python 
> I'm assuming each client needs their own Apache server.

Yes, that's how we ended up setting up our mod_python accounts.
We also found stability problems in some of the other mod_* modules 
(mod_webkit, mod_skunkweb, ...) and they sometimes crashed the main 
Apache server (very bad). So for all the frameworks that support a 
standalone HTTP server mode (CherryPy, Webware, Skunkweb, ...) we now 
set them up as standalone HTTP server listening on a local port, and we 
just use our main Apache server as a proxy to these servers.
This allows us to use the trick described on this page: 
http://www.cherrypy.org/wiki/BehindApache (look for "autostart.cgi") to 
have Apache restart the server automatically if it ever goes down.

>  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.

Well, the 2 main problems that I can think of are:
     - Python frameworks tend to work as long-running processes, which 
have a lot of advantages for your site, but are a nightmare for hosting 
providers. There are soooo many things to watch for: CPU usage (a 
process can start "spinning"), RAM usage, process crashing, ... But that 
is not related to python and any hosting provider that supports 
long-running processes face the same challenge. For instance, we support 
Tomcat and the problems are the same. For this we ended up writing a lot 
of custom monitoring scripts on our own (we couldn't find exactly what 
we needed out there). Fortunately, python makes it easy to write these 
scripts :-)
     - But another challenge (and this one is more specific to Python) 
is the number of python versions and third party modules that we have to 
support. For instance, at Python-Hosting.com, we have to support all 4 
versions of python: 2.1, 2.2, 2.3 and 2.4, and all of them are being 
used by various people. And for each version, we usually have 10 to 20 
third-party modules (mysql-python, psycopg, elementtree, sqlobject, ...) 
that people need ! We run Red Hat Enterprise 3, but RPMs for python are 
not designed to work with multiple python versions installed, and RPMs 
for third-party modules are usually inexistent. As a result, we have to 
build all the python-related stuff from source. And some of these 
modules are sometimes hard to build (the python-subversion bindings for 
instance) and you can run into some library-version-compatibility 
nightmare. And as if this wasn't enough, new releases of modules come 
out everyday ...
I think that this second point is the main challenge and any hosting 
provider that is not specialized in python doesn't have the time or the 
knowledge to build and maintain all these python versions and 
third-party modules. Of course, they could just say "we're going to 
support this specific python version with these few third-party modules 
and that's it", but experience shows that most people need at least one 
or 2 "uncommon" third-party modules for their site so if that module is 
missing they just can't run their site ...

But above all, I think that the main reason why python frameworks are 
not more commonly supported by the big hosting providers is because the 
market for these frameworks is very small (apart from Zope/Plone). For 
all the "smaller" frameworks (CherryPy, Webware, SkunkWeb, Quixote, ...) 
we host less than 50 of each, so the big hosting providers simply won't 
bother learning these frameworks and supporting them for such a small 
market.

--
Remi / http://www.python-hosting.com


More information about the Web-SIG mailing list