On Jun 25, 1:22 pm, Ben Bangert <[EMAIL PROTECTED]> wrote: > At this point, you're not talking about Pylons btw, you're talking > about Python vs the others.
Absolutely. PHP has most stuff compiled into C. mod_perl does some wonky stuff between perl and c. both are crazy fast with templating compared to Python. > 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. Yeah, that's a PITA and the largest reason why I dislike PHP -- even large systems are still 'scripts' , not appservers. You can mitigate that using stuff like the APC or eAcccelerator caches, and your app caching info -- but (as a bad allusion) that only affects how fast you go from 0-60 , not starting you off at 20. > 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. I haven't had to optimze anything yet. Most of the stuff I've offloaded was on clusters already - or is actually running faster than the Perl counterparts ( numerical matrix processing for stats. Python just blows perl away at that ) > 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). I think that's heart of why I love Pylons -- so what if its 'slow' , slow is usually 'fast enough' , and you're saving SO MUCH dev time. > 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. if i were you, the next thing i'd do to optimize is offload the DB. if you're db heavy and you've got a system that big, you're hitting a mem+cpu issue. i wouldn't be surpirsed if you could quadruple pylons' performance once the db is moved. > 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. That's a GREAT tip. I missed that in the docs. Wondering something about the Mako templating though... - are templates served from memory or processed through the data/ templates dir on every request ? > 2) Use cookie-based sessions, to avoid hitting the filesystem loading cookie based sessions are the devil. the best option would really be memcached --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
