Nimble Method

Advanced Performance Optimization of Rails Applications Presentation at RailsConf 2009

Things have never been so exciting! We come to RailsConf again and this time not to spectate, but to speak! 

I will be giving a talk on advanced performance optimization of Rails applications on May 5th at 14:50 PDT in Pavilion 9-10, Las Vegas Hilton, Las Vegas, NV. 

When I started working with Rails, little did I know that optimization doesn't end with speeding up my Ruby code (or Rails itself). The performance of production application heavily depends on its environment - server filesystems, databases, load balancing solutions. The browser plays the crucial role as well. 

In my talk I hope to not just share my knowledge about different aspects of performance optimizations, but put together all these pieces of the performance puzzle. I'll show with numbers what's important and what's not and share with you the performance-oriented practices and processes we developed in Pluron for the last 3 years.

Let me outline some examples to give you a taste of what I'll be talking about. It turned out that:

• when deploying on shared databases you need to optimize for cold database state in order to have 14x speedups for your SQL queries!
• using Date class with some of its functions rewritten in C can give you 2.5x speedup for free!
• inaccurate usage of $() and $$() functions on large pages will make your application in Internet Explorer 13x slower!
• proper load balancing will make your application perfectly usable without any optimizations in code at all!

Already curious? Join me at RailsConf and you'll learn even more. If you haven't registered yet, by all means do so here and don't forget the 15% discount code RC09FOS I have for you.

If you're interested in the talk, please leave a comment and let me know what you think of the topics I'm going to discuss. I'd love to hear what I'm missing, what you think is boring and what is particularly interesting for you.

Please also watch for updates in this blog. I'll be sharing slides here after the conference ends and I plan to write more detailed posts on each performance optimization topic.

See you at RailsConf!

---

PS: here's my presentation abstract for your reading pleasure:

Advanced Performance Optimization of Rails Applications

Alexander Dymo (Pluron, Inc.), 2:50pm Wednesday, 05/06/2009, Location: Pavilion 9 - 10

In this session Alexander covers steps of performance improvement process necessary to make real-world production Rails application fast and keep it so.

To start, your application is slow. Make it faster:

• optimizing common hotspots in Ruby code, including Date class, String::+=, BigDecimal comparisons and more
• preloading has_many/belongs_to associations when Rails eager loading can’t (custom joins and selects)
• optimizing template rendering, especially when including multiple small partials
• tips for faster PostgreSQL queries: manually pushing down conditions into subqueries, using arrays instead of joins and more
• performance characteristics of JRuby and Ruby 1.9

Two new plugins to make it faster faster:

• Virtual Attributes AR plugin
• Template Inliner plugin

Your application is fast on development boxes, but is still slow in production. Some things to look into:

• impact of filesystem performance
• shared database performance under severe memory restrictions
• debugging live production applications (strace, dtrace, oprofile)
• debugging performance problems caused by load-balancing solutions commonly used with Rails

Your application is fast on the server, but is still slow for the users. Optimizing in-browser performance:

• HTTP optimization basics, managing browser cache
• optimizing JavaScript performance, efficient drag-and-drop
• IE-specific optimizations Your application is fast.

Here are the best practices and processes to keep it fast:

• performance-aware coding and unit testing
• continuous performance integration testing
• memory profiling
• techniques for realistic database profiling
• production performance monitoring

Need to justify performance work to your boss? Alexander will use the data he gathered from production Rails application to demonstrate how quickly the performance degrades when you don’t care about it. You will understand that the continuous work on performance should be the integral part of your development and deployment process.

Performance Freak's View on RailsConf 2008

RailsConf is over and it's about time for reflections now. Two hot topics this year dominated the conference - we've got a strong presence from people working on alternative Ruby implementations and lots of presentations on scaling and performance. In short, my two conclusion on those topics are:

• one and only one MRI alternative now really works
• Rails community focuses on scaling rather than performance

Read on and I'll tell you what works and what to do if you want faster and not larger Rails.

Alternative Ruby

The current situation with alternative ruby implementations reminds me of the lions pride. The lion king (read MRI) is old and weak, but it's still strong enough to outperform the subadults. Despite that, some of the youngsters look promising, some them look cool and some look as undecidable. My personal opinion here is that promising implementations take existing VM and implement Ruby on top of them, cool implementation do all on their own and undecidable ones are not open source. Ok, enough generalizations, this topic deserves somebody to talk in details, so here are my stories on JRuby, Rubinius, Ruby 1.9, Iron Ruby and MagLev.

JRuby Story

I've been watching JRuby since its inception. I remember listening to Charles Nutter back in 2006 at RailsConf Europe when he demonstrated the first JRuby version that could run Rails. Cool, I said to myself and continued with MRI.

I also remember myself sitting at Charles' tutorial last year trying to get my application running under JRuby. At that time I spent 3 hours to get the app almost running - all Acunote functionality eventually worked except for burndowns because of broken RMagick. And of course our performance benchmarks showed the application became 3-5 times slower.

This year was a breakthrough. I was sitting through one of the presentations about scaling Rails when I thought that it's a good idea to try JRuby once again. So I did. In 15 minutes I got all JRuby stuff and required dependencies installed and Acunote running. That was a real "wow starts now" moment :) All code we have just worked. Ok, what's about the performance you might ask. I ran Acunote benchmarks and it turned out that JRuby shows exactly the same performance as MRI! And that's using old Java5 Client VM, postgres-pr driver written in Ruby and only 3 requests to warm up the VM. Once I'll get back home, I'll try using JDBC driver, recent JVM and issue more requests for benchmarking. The gut feeling is that JRuby will be faster in that case, watch for my next blog post if you're curious ;)

Rubinius and Ruby 1.9 Story

These guys have all the fun for sure, but they will simply need more time to implement their VM's right. As you see from my previous story, three years was enough to get JRuby really working. And bear in mind, they didn't have to write VM.

Despite that, I personally become more and more interested in Rubinius. As you might know, I'm KDevelop IDE developer and one of the guys who worked on Ruby support for KDevelop. Java support in Eclipse is so cool just for one reason - they have compiler built in that knows everything about your code. Rubinius looks like a perfect tool to do exactly this for KDevelop. It may be able to load all the code and keep it constantly running as you work on the project and IDE would be able to recompile changed bits of the code on the fly. This Smalltalk-like way is probably the only way IDE can know about all symbols in the code written in dynamic language. I'm definitely looking forward having some free time to play with that.

MagLev and IronRuby Story

MagLev today is even less than JRuby in 2006. It's still more like a proof-of-concept that you can run Ruby on Smalltalk VM rather than a product in development. It was quite cool to see Smalltalk-like object caches and stores working with Ruby. As somebody said, seeing two irb's working with the same global state was a mind-blowing experience :)

Anyway, during the next 3-4 years we'll see whether they survive and produce something useful. The only issue in my opinion with MagLev is that it is closed source. These days you have to have really really good product to compete with open source in the arena of languages, compilers and VM's. Time will tell whether MagLev will have that advantage.

Microsoft's IronRuby is slightly more mature (maybe because it runs Rails ;)) but still has a long way to go. IronRuby guys also did have some cool stuff to show us at their presentation. Their mind-blowing thing was the same Ruby application running on server (Rails app) and client (Ruby in Silverlight). Sounds cool, let's see where that will go.

Scaling vs Performance

I thought performance was going to be the hot topic this year. I was proven wrong. The majority of Rails crowd now thinks it's easier to "scale" rather than to "optimize". Yeah, good old "add more hardware" approach with some new techniques added to make that process easier.

Michael Koziarski was probably the only one to speak about performance and tell the right thing. The idea is that it's always possible to improve something in Rails application by optimizing it or even optimizing Rails itself and the process to do that is easy - measure to find what's slow, fix it and measure again.

This measure-fix-measure is not a revelation and there're great tools to do that like ruby-prof and KCachegrind (see my previous blog post on profiling). I just wish more people used it.

After RailsConf Jeremy Kemper did some great work in optimizing Rails further. Also it's cool to see that Jeremy added performance test generators into Rails. I do hope that those tests will help people to make performance improvement the integral part of Rails application development process.

Speaking about profiling, Scott Barron and Chad Humphries from EdgeCase did a nice presentation about using DTrace with Ruby. DTrace is what you can use instead of ruby-prof (or together with ruby-prof) on development machines for regular profiling. But more interestingly, thanks to its low resource footprint, DTrace can become the real-time profiling solution for your production app (in case you deploy on Leopard or Solaris). This way you would be able to find slowdowns that happen rarely or happen only under heavy load on production machines. I only wish I had such tool available on Linux (to profile Acunote of course).

Final Thanks

Wrapping up this overview, I'd like to thank all speakers for great talks, especially Yehuda Katz (DataMapper presentation), Jeremy Kemper (Rails 2.1 keynote), Michael Koziarski (Rails performance), Adam Pisoni (Skynet) and Stephen Midgley (Complex searching in Rails) for the in-depth high-quality technical talks I've enjoyed so much.

I had a great time at RailsConf and hope you did that too, see you next year.