On Nov 15, 2009, at 2:03 PM, kevbaker wrote:
>
> I am working on optimizing our Pylons servers for better performance.
> Currently I am getting what I would consider pretty poor performance.
>
> I have some data and questions.
>
>
> = Questions
> 1. Does Pylons take advantage of multiple processors on my server?
Yes, it generally runs via a multi-threaded web server like Paste http server,
CherryPy, or mod_wsgi Apache, or even J2EE containers under Jython. Of course
how much parallelism you can really get is hindered by Python's Global
Interpreter Lock.
> 2. Other than shutting off debugging what can I do to improve
> performance?
The easiest gain is to serve the static files (in the public/ directory) via a
faster frontend server like Apache, nginix, or a CDN. To really reap the
benefits of this, you must switch the static_files flag in the ini file to
false. Then Pylons no longer checks if URLs are for a static files (which takes
precedent over everything else) during every request.
> 3. Are there any other options outside of Paster and Cherrypy? Which
> should I use?
There's also FAPWS, Spawning, and some others. Try mod_wsgi if you're trying to
squeeze out every bit of performance.
> = Configuration
> - Pylons 0.9.6.2
> - Amazon EC2 c1.medium, 1.7 GB Ram, 5 EC2 Compute Units (2 virtual
> cores)
> - Ubuntu 8.04.3
>
>
> = Data
> - Running Apache Benchmark to get usable numbers to measure
> performance improvements after config changes. All tests were using
> "ab -n 400 -c 10 {MY URL}"
> - Pylons direct, no proxy, load static file - response:36.86
> - Pylons direct, no proxy, load template file with a few variables -
> resp/sec:30.28
> - Pylons direct, no proxy, load template with database query - resp/
> sec:16.06
Regardless of what you do with Pylons your database is the larger bottleneck in
at least some cases. On the Pylons side, assuming you're using SQLAlchemy, you
can speedup some operations by using the SQL expression layer directly instead
of the ORM layer, to avoid its object creation. However the data i/o is
probably a larger hit. Consider caching some of it.
More important than anything I've said is to benchmark your app and go by the
numbers.
--
Philip Jenvey
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
