On Jun 24, 2008, at 5:38 PM, Jonathan Vanasco wrote:

At this point, you're not talking about Pylons btw, you're talking about Python vs the others. And depending on what you use in mod_perl or PHP, you'll get very different results. I've seen several performance numbers showing PHP based apps using Cake and the other 'cool' PHP frameworks running sometimes significantly slower than the Pylons version. This is mainly due to PHP not having a persistence execution environment, so loading the framework every request becomes a burden.

Pylons is a bit more efficient than some of the other frameworks by evaluating many things in a lazy fashion. Sessions aren't loaded or touched until you use them, request parameters aren't parsed until you access them, etc.

And the PHP framework load time will severely affect performance of it.

I'm curious what you did to optimize your deployment environment. That's really what it all hinges on. Especially if you're writing CPU bound applications, and failing to use additional processes to take advantage of multi-core systems that the mod_perl and PHP ones will use due to how they're deployed. As George noted, the numbers changed quite a bit as he changed his deployment.

For my own production app, which does a rather significant amount of database queries and complex template rendering (on every single page), with no additional tweaks or performance tuning of the database end it ran at about 18 req/sec. Slow? You bet, I traded performance for the ORM layer's overhead, and I was hardly efficient in how I wrote my templates (I used lots of extra functions as they saved me time).

However, the app was CPU bound, and it was on a 8-core server, so I spawned 8 paster processes, and load balanced to them from nginx, which changed the 18 req/sec to 104 req/sec. 104 req/sec is 6,240 req/ sec a minute, or 8.9 million requests a day. That's just a single server, which also has the entire database on it (which is around 30gb of data). This is not a small app, I consider those numbers quite speedy, especially given that I'm not caching data, and I'm not really trying to keep my code super optimized.

Another few things that can increase performance (which I haven't felt the need for yet, but they do help): 1) Turn off Mako's template checking, Mako hits the filesystem every template render to see if the template has changed since last time, in production you likely don't need this as your templates only change when you update the deployment. That's a good amount of filesystem hits that will go away. 2) Use cookie-based sessions, to avoid hitting the filesystem loading session data. You'll still need to hit the database on occasion to ensure the user is logged in, but this can avoid the file-system hit as well.

Cheers, Ben