views:

118

answers:

3

There are many ways to deploy Pylons apps. - Proxying through apache or nginx to paste - Embedding the app with mod_wsgi - using some edgy nginx+uwsgi combo - and probably more...

I've read a lot about the various approaches but failed to really decide which one to choose.

Proxying to paste through nginx seems to be the easiest method to setup, but is it efficient? Wouldn't paste be slower than mod_wsgi or uswgi? If so, is the performance increase worth the hassle?

Need some experts to help me choose the best compromise... I want simplicity, but I need decent (if not cutting edge) performance, and you, Obiwan Kenobi, are my only hope ;)

+1  A: 

The best answer is, it depends.

From a pure simplicity standpoint, apache2/mod_wsgi is probably the easiest to manage since you have a much larger pool of people that understand apache.

From a performance standpoint, it depends.

If your application is very framework heavy and not very static content (css, images) intensive, the gateway between the webserver and pylons is more likely your bottleneck and almost any deployment can handle that.

Paste is fairly quick. I found nginx/uwsgi's interface to be slightly quicker than apache2/mod_wsgi. nginx's static file performance and memory requirements favor nginx as well.

There are a few sites I've come across that talk about both:

tonylandis.com/python/deployment-howt-pylons-nginx-and-uwsgi/ cd34.com/blog/programming/python/pylons-and-facebook-application-layout/ code.google.com/p/modwsgi/wiki/IntegrationWithPylons

The comparisons I've done are with apache2/mpm-worker rather than mpm-prefork as I didn't need mod_php5 in my setup.

karmawhore
Huh. The gateway between the web server and Pylons would practically never be the bottleneck. The overhead of hosting mechanisms, except for CGI at least, is so minimal that in practice for a real system (not a hello world program) there is going to be little difference between different hosting mechanisms. Instead the bottleneck will be the application, rendering systems and databases. Not sure what you intended to mean, but it doesn't really come across sounding right.
Graham Dumpleton
+2  A: 

If performance is most important, look at some tests:

http://wiki.pylonshq.com/display/pylonscookbook/Some+performance+test+results

Maciej Kucharz
+2  A: 

What I meant to say is that if the application is more framework dependent than static content dependent, the limiting factor would be the webserver -> framework and I've found negligible differences in the performance of nginx -> uwsgi -> pylons and apache2/mpm-worker -> mod_wsgi -> pylons as the limiting factor is Pylons. This isn't to mean that Pylons is slow.

No matter which deployment method I used with repoze.who/what, I found it difficult to scale past 280 requests per second per CPU core.

@mkucharz, As for those performance results, those results are three years old and don't even come close to configurations that exist today. Pylons 1.0 is about 10% faster than 0.9, flup is much more mature, and that doesn't test uwsgi or mod_wsgi. It also uses Mighty rather than Mako, also pointing to the test's age.

The other hidden variables include the version of Python. In some distributions, I've found Python 2.5 to be a little faster than Python 2.6 depending on what the application does.

Disclaimers:

  • Pylons is not slow.
  • mod_wsgi and uwsgi performance differences are negligible in production settings.
  • Nginx's static file performance is better than apache.
  • Apache/mpm-worker is much faster than mod-prefork if mod_php isn't needed.
  • Almost any deployment that you understand is probably enough for 99% of the webapps out there.
  • 99% of the published benchmarks don't properly test an environment. Hitting a page 10000 times is not indicative of real world performance.
  • Trying to be helpful when posting late at night never works. I knew when I saw this come up on tweetdeck I should have just said nothing.
karmawhore