mod_python or fcgi

[Rufman]

Hey

I was wondering: Is Django faster and stabler using mod_python or
fcgi?

I read that mod_python can be a memory hog...what are the concrete
advantages of using fcgi or mod_python for that matter?

any ideas/tips, thanks

Stephane

[Graham Dumpleton]

On Apr 24, 12:57 am, Rufman <stephaneru...@gmail.com> wrote:
> Hey
>
> I was wondering: Is Django faster and stabler using mod_python or
> fcgi?
>
> I read that mod_python can be a memory hog...what are the concrete
> advantages of using fcgi or mod_python for that matter?

That mod_python can be a memory hog is a bit of a myth. Yes it does
have a base level memory consumption which is a bit more than
necessary, but complaints about mod_python being really fat actually
stem mostly from having a Python installation that didn't provide a
shared library for Python. Lack of a shared library results in Python
static library being incorporated in mod_python Apache module. When
that was then loaded, because address relocations had to be performed,
it became process local memory, thus adding a few MB to size of
process. If shared library for Python is correctly used, this doesn't
occur.

As a result, the per process memory requirements of mod_python and
fastcgi aren't that much different when looked at in the greater
scheme of things, in as much as your actual Django application is
chewing up 40-60MB of memory where as mod_python and fastcgi will be a
lot less than that. In other words, be more worried about how much
memory your Django application is chewing up rather than the hosting
mechanism.

That all said, mod_wsgi is possibly a better choice than both. This is
because in its mode where it works like mod_python it has less base
level memory overhead than mod_python. On top of that it also supports
a mode which gives similar properties to fastcgi. Thus mod_wsgi can do
what both of these other systems do in the one package.

The mod_wsgi package also has less performance overheads, although
like with memory, the real bottleneck is your Django application, plus
any database accesses.

Other things you need to consider are whether you use Apache prefork
or worker MPM. With prefork you will have a lot more instances of your
fat Django application, thus overall memory usage is more. You should
therefore look at whether your application is multithread safe and use
worker MPM instead, or use mod_wsgi daemon mode with a single or small
number of multithread processes.

Graham

[Rufman]

Hey Graham

thanks for the insight

Stephane

On Apr 24, 2:22 am, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:

[Don Spaulding]

On Apr 24, 6:34 am, Rufman <stephaneru...@gmail.com> wrote:
> Hey Graham
>
> thanks for the insight
>
> Stephane

I won't debate any of what Graham has said, as it's a pretty standard
answer from what I've seen, and he's a lot smarter than me. I just
want to note that fastcgi makes a nice separation between app and web
server for my needs. I hated having to restart apache to restart my
app, and fastcgi on lighttpd made app deployment stupidly easy (not
that apache/mod_python is rocket science).

Don Spaulding

[Graham Dumpleton]

When you use mod_wsgi daemon mode, to restart your Python web
application, which can potentially be running across multiple
processes, you just need to touch (ie. update its modification time)
the WSGI script file which is its entry point and process will be
restarted automatically the next time a requests arrives for them.

In other words, with mod_wsgi daemon mode you do not have to restart
the whole of Apache when you change the code just for your Python web
application. Thus, just as stupidly easy as some fast fastcgi
implementations/configurations. :-)

Graham