mod_wsgi vs cherrypy

Mike McGrath mmcgrath at
Thu May 8 16:45:14 UTC 2008

As many of you have seen we've started getting timeouts with fasClient
against the accounts system.  After some probing I decided to look at
alternate deployment methods.  Bottom line... python threading blows.

So here's the scoop.  Right now we use cherrypy + supervisor to deploy
each turbogears app.  Each app gets its own port.

WSGI also relies on cherrypy but does things in a different way.  mod_wsgi
is an apache plugin, and instead of every app getting its own port, it
gets its own apache namespace (like /accounts/)

mod_wsgi can be setup to deploy more then one process at a time and send
requests to both.  Straight tg + cherrypy cannot do this unless you have
two instance listening on different ports and have a load balancer in
front sending to both ports.

So I ran some tests.  (attached and at -  After proper tuning
for the machine mod_wsgi was not only a little faster (20 seconds faster
in the extreme end) it was also considerably more reliable and scaled
predictably.  Straight cherrypy would reliably die on me at around 40
concurrent requests.  Those requests would complete but sometimes timeout
or take too long for the client to listen.  I think this is helping
attribute to whats going on in our environment.  The test in question was
/accounts/group/list (its not a quick/small request)

There's other code changes on the way but I think mod_wsgi is a win for us
in this instance.  After the freeze I'd like to deploy it on the fas
boxes and see how things go.  We should then talk about our other
deployments.  I like supervisord but it may be better for us in the long
run to use apache straight up.  Also we get some other niceties like
able to more easily serve static content, and all the
mod_[headers,rewrite] stuff as well that comes with apache.

Thoughts, questions, comments?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wsgivscherrypy1.png
Type: image/png
Size: 18632 bytes
URL: <>

More information about the Fedora-infrastructure-list mailing list