Don't use mod_python

http://wiki.python.org/moin/PoundPythonWeb/mod_python

by rams • 18 years ago

29 13 18 years ago

wiki.python.org

wave• 18 years ago

Is there any merit to this wiki? The author isn't known but does the stated reason worth abandoning mod_python? I don't think so.

j2d2• 18 years ago

The wiki is primarily discussing theory of administering a web system with a little bit about resource distribution. The ideas all have merit, but you need to decide how important they are. I, for example, don't mind having to upgrade a webserver, language and module simultaneously. I don't do this on production systems, so my services won't go down. I'll build the new system, test it, replace the old one and that's that. It's not really an issue to upgrade a few pieces of software together in the full scope of my testing processes.

rcoder3• 18 years ago

This of course disregards the #1 reason to use mod_python (or mod_perl, mod_ruby, or any other fully-integrated scripting language Apache module): namely, because you're not just limited to generating dynamic content.

The Apache request-handling chain is much richer than simply passing off incoming requests to a CGI or PHP script. Using mod_{perl,python,ruby,etc.}, you can implement authenticators, URL-rewriting modules, log handlers, output filters, etc., and take advantage of the mature Apache infrastructure for such code.

Basically, if you want to be able to slice and dice HTTP requests at every stage of processing, not just the content-generation one, the Apache mod_* add-ons are a pretty powerful tool for doing just that.

hobbs• 18 years ago

You can get all of that by using mod_rewrite/mod_fastcgi/mod_wsgi to passthrough to a full-blown Python app server running behind the web server as a separate process. All of the other mod_* authentication and authorization hurdles will still be evaluated first.

rcoder3• 18 years ago

While it may be possible to get the same level of control over the request lifecycle using mod_rewrite and simple dynamic content generation, it can often be awkward and slow compared to doing the same thing via a full-blown Apache scripting module like mod_python.

Case in point: I'm currently working on an application that uses mod_auth_kerb to perform Kerberos password authentication on behalf of users, then fork a background server which has access to that user's Kerberos credentials, and proxy future connections from that user to the dedicated backend.

Doing that using mod_rewrite requires using the RewriteMap 'prg:' map type, which introduces a single choke-point in the application: namely, the single script responsible for spawning the backend servers. That script also runs in the one Apache master listener, which means that no other incoming requests will be answered until the rewrite script returns its output.

If I were instead using mod_perl (as I suspect I will be, before this moves into production) I would be able to have each Apache child process handle its own forking of backends for requests it was handling.

davidmathers• 18 years ago

A very unconvincing list.

1. That's what package managers are for.

2. If you're in the position of configuring your own web server then this probably doesn't matter to you.

3. See #1.

4. True, but your /usr/bin/python processes will be lighter because they won't exist.

5. I have no idea if this is true, but no evidence is provided.

6. My personal experience with mod_proxy has been...unhappy.

7. ???

8. See #5.

DanielH• 18 years ago

Basically you should use mod_wsgi these days...

simonw• 18 years ago

Yup. mod_wsgi is written by one of the core mod_python maintainers and is essentially a much more modern take on the whole problem of running Python code within Apache. It's powerful, flexible, easy to configure and it even works well with shared hosting (you can give each user their own process group which restarts when they "touch" a file in their home directory). I'm a total convert.

alexk• 18 years ago

Mod_python seems to be very promising and robust from the first sight. I've tried mod_python and it left me delighted for several reasons; some of them:

1. You can get total control over the request.

2. Mod_python provides a set of wrappers to mimic standart python CGI objects what greatly simplifies your life

3. Basic load tests say that mod_python is robust and fast

4. Installation is easy

The only thing that I've found confusing is unicode support (take a look at http://www.modpython.org/pipermail/mod_python/2004-June/0158...)

The only thing that I need to know about mod_python - is the list of successful commercial deployments.

What about the cons, I would also like to know who are these guys from this PoundPythonWeb, they look like someone official, but I'm always feel suspicious when someone says: "Don't use this" (except the case when the person is the author :))

smoody• 18 years ago

"...which makes wsgi applications (which can be deployed through several ways) very flexible..."

What are the preferred ways to deploy wsgi apps?

tlrobinson• 18 years ago

I'm currently just using mod_python for my Trac installation, but it's ridiculously slow. Any suggestions?

Edit: I switched to using fcgi and it's wayyyy faster. So there's reason #9.

clintavo• 18 years ago

I thought the whole point of mod_python was performance. Since it runs inside the apache process it doesn't have to spawn a new python interpreter for every page request. Am I mistaken? Does fastcgi and/or mod_wsgi solve the same issue?

rcoder3• 18 years ago

All three work if your goal is simply to avoid forking a new Python interpreter for each incoming request, ala CGI.

The difference is in where they hook into the request-handling workflow within Apache. Both FastCGI and WSGI apps only receive the request after Apache (or lighttpd, nginx, et. al.) have finished doing access control checks, URL rewriting, header parsing, etc.

Code inside the mod_python interpreter, on the other hand, can hook in to any of those earlier stages of request processing, which allows it to do things like block a request, alter the Apache log format, or look up a vhost docroot in a database, all before any content is generated.

The downside is that each and every Apache process on your server has a full copy of the Python interpreter embedded inside, which can cost you a pretty serious chunk of RAM when you start dealing with servers running 25-50 (or more) httpd processes.

Don't use mod_python

Related Stories