event mpm?

[cmawe...@gmail.com]

I'm trying out Ubuntu 14.04 and noticed the default apache2 mpm is now event. I use daemon mode for wsgi. Is there any advantage to switching the mpm to threaded? Are there any known issues with using the event mpm with wsgi?

[Graham Dumpleton]

On 06/05/2014, at 2:07 AM, cmawe...@gmail.com wrote:

> I'm trying out Ubuntu 14.04 and noticed the default apache2 mpm is now event. I use daemon mode for wsgi. Is there any advantage to switching the mpm to threaded? Are there any known issues with using the event mpm with wsgi?

I know of no issues with using event MPM with mod_wsgi.

When you ask 'Is there any advantage to switching the mpm to threaded?' does that mean you were previously using prefork MPM?

Using prefork has various issues, although if you are using daemon mode you most avoid them.

If using prefork MPM though and daemon mode exclusively, you should at least ensure you disable the Python interpreters in the main Apache child processes to reduce memory usage and startup time for those processes.

http://blog.dscpl.com.au/2009/11/save-on-memory-with-modwsgi-30.html

As to event MPM vs worker MPM, the event MPM is supposed to better in various ways, especially in how it handles keep alive connections. But then, keep alive connections can themselves be dangerous and affect server capacity. Generally would recommend nginx be placed in from of Apache if keep alive with client is important. With nginx in front it will handle keep alive with less resources and you would turn it off in Apache.

Anyway, as usually various pros and cons of different approaches and to a degree what you should use depends a lot of your specific Python web application. In other words, you can't necessarily make decisions about the server architecture and configuration without taking into consideration your specific Python web application.

Some stuff to watch if you haven't before.

http://lanyrd.com/2012/pycon/spcdg/
http://lanyrd.com/2013/pycon/scdyzk/

Graham

[Collin Anderson]

I'm coming from using nginx + apache2 worker_mpm. Good to hear there
are no known issues with the event mpm.

> --
> You received this message because you are subscribed to a topic in the Google Groups "modwsgi" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/modwsgi/KrVudZx7mbA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to modwsgi+u...@googlegroups.com.
> To post to this group, send email to mod...@googlegroups.com.
> Visit this group at http://groups.google.com/group/modwsgi.
> For more options, visit https://groups.google.com/d/optout.

[John Moylan]

I've been using event MPM with mod_wsgi and Apache 2.2 for over 4 years now on very heavily trafficked sites. I have keepalive turned off but I have still noticed reduced server resource usage and that makes it worthwhile for me. One caveat with the event mpm in 2.2 was that you couldn't use it with apache filters - not sure if this is the case with Apache 2.4 though.

[John Moylan]

Another good alternative to Nginx infront of your server is Varnish - it handles Keepalives very well. I usually see at least a 10/1 ratio between requests and connections due to Keepalive in Varnish on my systems.

[Graham Dumpleton]

On 15/05/2014, at 9:01 PM, John Moylan <jo...@nuatech.net> wrote:

I've been using event MPM with mod_wsgi and Apache 2.2 for over 4 years now on very heavily trafficked sites. I have keepalive turned off but I have still noticed reduced server resource usage and that makes it worthwhile for me. One caveat with the event mpm in 2.2 was that you couldn't use it with apache filters - not sure if this is the case with Apache 2.4 though.

The Apache 2.4 documentation still notes:

The improved connection handling may not work for certain connection filters that have declared themselves as incompatible with event. In these cases, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection. All modules shipped with the server are compatible with the event MPM.

A similar restriction is currently present for requests involving an output filter that needs to read and/or modify the whole response body, like for example mod_ssl, mod_deflate, or mod_include. If the connection to the client blocks while the filter is processing the data, and the amount of data produced by the filter is too big to be buffered in memory, the thread used for the request is not freed while httpd waits until the pending data is sent to the client.

Graham