On 18 March 2010 05:19, Alec Flett <[email protected]> wrote:
>
> On Mar 1, 2010, at 5:39 PM, Graham Dumpleton wrote:
>
> BTW, I have never seen you post about what version of Apache you are
> using, nor what operating system/distribution you are using.
>
>
> Sorry just getting back from a long vacation. So to answer the easy
> questions:
> - Gentoo 1.12.11.1 (though we are switching to Fedora literally today, so
> we'll see if this problem goes away)
> - Apache config on Gentoo:
> Server version: Apache/2.2.9 (Unix)
> Server built:   Jan 15 2009 18:47:53
> Server's Module Magic Number: 20051115:15
> Server loaded:  APR 1.3.2, APR-Util 1.3.2
> Compiled using: APR 1.3.2, APR-Util 1.3.2
> Architecture:   64-bit
> Server MPM:     Prefork
> threaded:     no
>   forked:     yes (variable process count)
>
> - Apache config on Fedora 11
> Server version: Apache/2.2.11 (Unix)
> Server built:   Mar 17 2009 09:15:07
> Server's Module Magic Number: 20051115:21
> Server loaded:  APR 1.3.3, APR-Util 1.3.4
> Compiled using: APR 1.3.3, APR-Util 1.3.4
> Architecture:   64-bit
> Server MPM:     Prefork
>   threaded:     no
>     forked:     yes (variable process count)
> One thing we noticed was that it says "Threaded: no" - now obviously that's
> how prefork works, but do we need threading somehow enabled in APR?

You only need threading in APR if you want to be able to use daemon
mode. If APR doesn't have threading the WSGIDaemonProcess directive if
used will be rejected when Apache is started.

> I did address most of the issues you talked about before - i.e.
> WSGIRestrictEmbedded, upping the debug level, etc. I'll post more of what
> you asked for in the next few days.

I perhaps didn't see in response the information I was expecting in
order to clarify that and what the results may have been.

> More below.
>
>
> Thanks for all that explanation - this definitely clears up quite a bit for
> me as far as how mod_wsgi actually functions under the hood!
>
> If you are not handling dynamic requests of any form in the Apache
> server child processes, be it PHP, Python, Perl etc, then there is
> generally no reason to set MaxRequestsPerChild to anything but 0. If
> Apache is as such only handling static file serving and/or proxying to
> mod_wsgi daemon processes, then worker MPM would be much better choice
> than prefork as have mentioned before.
>
> Similarly, unless you have issues with resource leakage in your Python
> application, I wouldn't use maximum-requests to WSGIDaemonProcess
> either. For a site with large amount of traffic, would certainly be
> cautious about setting it to to low a value, ie., 1000, if it could be
> causing processes to be recycled within a matter of seconds.
>
> this is really great advice - it fits with my intuition, but I wasn't
> trusting my intuition :)
>  I didn't see these specific guidelines anywhere on the Google Code wiki,
> I'd definitely recommend putting them up there!

It doesn't say anything in documentation because neither of them is a
default for Apache or mod_wsgi and assumed that people would try and
understand the consequences of using them before actually turning them
on. Unfortunately various blog posts use them in examples because they
were using web applications that would accumulate Python objects over
time and not release them properly. Just because they were used for a
specific example doesn't mean it is a good idea in all cases. :-)

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en.

Reply via email to