Re: Isolated: Was: ModPython + Virtual Hosting Apache2 instance = poor performance.

Graham Dumpleton <[email protected]> Mon, 8 Mar 2010 13:59:16 +1100
Newsgroups gmane.comp.python.mod_python
Message-ID <[email protected]>
On 8 March 2010 13:42, Christopher Sean Hilton <chris-7VRIiXHg8cFWk0Htik3J/[email protected]> wrote=
:
>
> On Mar 7, 2010, at 6:06 PM, Graham Dumpleton wrote:
>
>>
>> You said you were using PHP, so you cant use worker MPM with Apache.
>> You can still use mod_wsgi with prefork MPM, just ensure you run WSGI
>> application in daemon mode of mod_wsgi to avoid issues discussed in
>> article. Do note though that you can't use mod_wsgi with a Python
>> installation which hasn't been compiled with thread support. You also
>> cannot use daemon mode with a APR library for Apache that doesn't have
>> thread support.
>>
>
> Thanks for the tip, That would have been a real huge problem.
>
>> Rebuilding Python without threading should not cause such a dramatic
>> improvement especially considering I recollect you had only loaded
>> mod_python and not used it. I would suggest your rebuilding has seen
>> some other change. I also don't know what earlier post you are talking
>> about as there was no such post in this current thread on mod_python
>> list.
>>
>
>
> I didn't make any quantitative measurements. Here's what I observed:
>
> Browsing this page with the "broken" configuration took approximately 1=
min to load all of the thumbnails. In the "fixed" configuration it loads =
instantly. N.B. that I'm looking at this over 100Mbit LAN.
>
> =A0 =A0 http://fileshare.vindaloo.com/SoccerPhotos/page-0001.html
>
> The thread Martin pointed to seemed to conjecture that the problem has =
to do with apache under FreeBSD being single threaded and thus depending =
on libc.so while a threaded python and thus a mod_python built to use it =
depends on libc_r.so. I believe the thread mentions a patch by you but it=
 may be a different Graham.
>
> =A0 =A0 http://osdir.com/ml/apache.mod-python.devel/2008-10/msg00000.ht=
ml
>
> I confess that I didn't understand the whole thing. What I took from it=
 is that I'm going to have problems using a non-threaded apache with a th=
readed mod_python. I tested this conjecture by building a fresh FreeBSD i=
nstall with fresh installs of apache 2.0.63, python2.6 and mod_python. An=
d I can make the problem appear and disappear by simply changing the conf=
iguration of the python 2.6 build from threaded to non-threaded. I feel t=
hat I may have the logic about the reason wrong. I think its a weird libc=
.so vs libc_r.so issue. But I'm confident that I've trapped the problem.

Don't know then. Not what I would have expected unless there is a
conflict in PHP or elsewhere in Apache with forcing use of rentrant C
library.

> To tell the truth it doesn't matter. My end goal is to run Django and n=
owadays Django want's mod_wsgi so I'm moving over there. What I'm learnin=
g talking to you is that as far as performance goes python want's a worke=
r MPM apache which php cannot do.

No, neither mod_wsgi or Python require Apache worker MPM. You can
still use mod_wsgi with Apache prefork MPM, thus allowing you to still
use PHP, but you would want to ensure you configure mod_wsgi such that
it creates a separate daemon process group to run your Django instance
in, similar to how FASTCGI works. This separate daemon process group
can be multithreaded, regarded of fact that single threaded Apache
prefork MPM is used, and so can have a single Python process, keeping
memory footprint down. It is because the mod_wsgi daemon process
supports threading that Python and APR have to also support threading,
even if you aren't using threading in main Apache server processes
managed under prefork MPM.

Perhaps have a read of:

  http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

Graham