[Zope-dev] ZPublisher/ZServer interaction (was Re: A modest proposal)

[Phillip J. Eby]

At 10:23 AM 10/12/01 -0400, Paul Everitt wrote:

>Wow, this is one hell of a thread. :^)
>
>FWIW, Grisha put a Bobo publisher in mod_python a couple of years ago. 
>Thus, if you like ZPublisher-style processing, you can do it in Apache via 
>mod_python.

Personally, I prefer to keep a process boundary between Apache and my apps, 
for both safety and security.  Usually they're running as different users, 
for one thing.  We've been very pleased with FastCGI performance using 
mod_fcgi, so I don't see a whole lot to be gained by using mod_python.

Another interesting factor that can affect performance is that we usually 
run many pre-forked Apache child processes, but rarely have more than 2 or 
3 application processes.  Using mod_python would probably impact memory 
usage adversely, since there would then be in effect a larger "application 
pool".

A somewhat simplistic analysis of memory usage in the different approaches:

O = Fixed application overhead (e.g. Python modules)
D = Application dynamic data
A = size of an Apache process
P = Memory used for a python interpreter (if the OS shares executable 
segments, ignore the code size, as it will be a constant for all approaches 
and thus irrelevant for comparison purposes.  In that case consider P will 
be the interpreter's data size)

n = Number of threads or processes in the app server pool
s = Number of Apache servers


Zope w/Apache frontend = P + O + D*n + A*s
mod_python             = (P+O+D)*s   + A*s
ZLite                  = (P+O+D)*n   + A*s

Since "n" is usually smaller than "s", the ZLite approach uses considerably 
less memory than the mod_python approach, but can be faster than the 
Zope+Apache combination on multi-processor machines when the Python 
interpreter lock is an issue, at an extra cost of only (P+O)*(n-1).  In our 
situations, that usually amounts to at most 2 or 3 times P+O, which is a 
small price to pay for also being able to ignore all threading issues.