Tips on how to improve application efficiency
Posted by marcel June 14, 2006 @ 06:51 PM
Rails performance specialist Stefan Kaes, who writes extensively about optimizing Rails over at Rails Express has a lengthy article at the new InfoQ site called A Look at Common Performance Problems in Rails.
Kaes identifies various development practices that will slow down your Rails applications, such as repeating computations that only need to be run once and then cached. If you’ve located some slowness in your application, Kaes may have already identified some of the likely culprits.
It’d be really great to see real life examples of these practices.
weak article for the rails blog to link to. all of those tips were pretty much useless to someone with any programming background.
and anyone doing web programming where performance matters at all had better know that a join is faster than 30 select statements.
Other Performance Tips:
Watch your development.log for your important page loads. See the SQL being called, and figure out what can be optimized.
Use memcache for everything (aka ActiveRecord), not just sessions.
Not everyone learning Rails is a professional web developer yet. And the more tips that get out there, the more good web applications we will have. This is a Good Thing.
I wrote a HOWTO to make memcached work with Typo here:
http://fak3r.com/articles/2006/05/11/speed-up-ruby-on-rails-with-memcached
Pretty useful article for those that don’t know.
I also set PostgreSQL to log slow queries (which log regardless of whether Rails is in development mode).
how do you set postgresql to only log “slow” queries?
log_min_duration_statement in postgresql.conf.
couldnt believe few things which author claimed.
like, 200% performance improvement by hardcoding URL’s instead of using routing
the tone of the article is not authoritative and is not supported by perf stats.
“but Postgres seems to be a lot slower for session storage than Mysql with MyISAM tables”
need to test them personally, before even assuming author was right.
but we already knew all or most of what was said, on other sites on scalability and performance of rails apps
the article didn’t include perf stats on purpose. you can find these on my blog in abundance http://railsexpress.de/blog