On Nov 21, 1:37 pm, BartlebyScrivener wrote:
On Nov 20, 3:39 pm, Graham Dumpleton wrote:
This only holds if actually hosted on Apache. As Django these days
supports WSGI interface there is nothing to stop it being run with
other hosting solutions that support WSGI. So, you could host it under
paster or CherryPy WSGI servers. You could even run it under CGI if
you were really desperate using a CGI-WSGI adapter. So, it isn't
strictly correct to say it is as a multiprocess framework specifically
for mod_python, although the developers will admit in the first
instance that they didn't design the internals with multithreading in
mind. That said, there aren't believed to be any multithreading issues
in Django itself at this time.
People keep pushing this barrow about the GIL and multithreading being
a huge problem, when in the context of Apache it is isn't, at least
not to the degree people make out. The reason for this is that when
using worker MPM it sill acts as a multi process web server even
though each process is also multithreaded. Within those worker MPM
child processes there is also a lot going on that doesn't involve
Python code nor the GIL, for example initial request process and
serving up of static files etc.
Result is that the Python GIL is no impediment when using Apache on
UNIX to making good use of multiple processors or cores, even when
Apache worker MPM is used.
I understand about a fifth of this exchange but I'm glad it's here so
I can follow links and search on the terminology. I couldn't tell from
earlier posts if mod_python was good or bad.
Version 3.3 of mod_python fixed up a lot of issues that existed with
older versions of mod_python. There are still a lot of issues in
In the main people will not run into these issues, of if they do, the
incidence of them causing a direct or significant impact is low, or
with people just tolerating the problems.
If you want to be where hosting with Apache is heading, then look at
mod_wsgi (http://www.modwsgi.org) instead. People will say I am biased
because I wrote it, but I was also the main person who did the more
recent work on fixing up mod_python and am more aware than others of
what problems still exist in mod_python.
To be frank, unless some white knight comes along and dives into
mod_python and fixes up the remaining issues, then you probably will
not see any significant future updates to mod_python and it will just
stagnate. I certainly will not be devoting much time to mod_python any
Part of the problem with mod_python is that the code base has grown
over time and is long overdue for a complete rethink, which is in part
what mod_wsgi was about, ie., making the code and configuration a lot
simpler and safer for use in web hosting environments.
Thus mod_wsgi takes aspects of what mod_python does, combining it with
aspects of how FASTCGI solutions work. This gives the option of
embedding a Python application in Apache for maximum speed, or using
daemon processes as means of being able to better separate multiple
Most importantly, mod_wsgi supports WSGI directly, making it
reasonably trivial to run any Python web framework or application
which supports the WSGI standard.
The Django book says: "Apache with mod_python currently is the most
robust setup for using Django on a production server."
Is that true?
I would say that that is now debatable. Overall mod_wsgi is probably a
better package in terms of what it has to offer. Only thing against
mod_wsgi at this point is peoples willingness to accept something that
is new in conjunction with Linux distributions and web hosting
companies being slow to adopt new packages.
Various people are quite happily using mod_wsgi. Users of mod_wsgi
range from people trying to run it in memory constrained VPS systems,
right up to major sites serving up to between 3-4 million hits a day.
There have been a few odd things come up since the initial release
which have since been fixed, but the core is showing itself to be very