Ruby on Rails has been around long enough to get past most of the hype. It is a robust web app framework with a lot to offer. One big drawback seems to be the general lack of performance that many rails apps have. Well, it turns out that there are several things that can be done for that.

First off, go read Charlie Savage’s article on tips to tune your rails app. Charlie discusses profiling your ruby app, and then tracking down the problem areas that are hurting performance. He was able to get his response times down from 7.8 seconds to 0.92 seconds! Wow.

Ok, so what about the case where you’ve tweaked your app, and wrung every last bit of performance you can out of it? But it still isn’t enough. You still cringe everytime your site makes the digg front page. Well, if you have your own servers, you can ensure that you have a scalable architecture. Theo Schlossnagle has a great book on the subject, Scalable Internet Architectures. This book discusses the various issues that a system designer faces when organizing the hardware that a web app will run on. Things like having optimized “static content servers” to stream image assets and css, along with more advanced techniques like setting up a caching proxy for each of your application servers since their CPU time is precious, and should not be wasted shoving content down a slow bandwidth pipe. He also goes into basic database design and advanced logging techniques.

Almost all of the techniques that Schlossnagle talks about are for larger installations, however he also spends time talking about scalability. Particularly the need to be able to scale down as well as up. For example, let’s say you are a fresh new startup, flush with VC cash. You go buy twenty servers, and fill ’em all up with world changing web 2.0 goodness. Six months later realize that the money will run out four weeks before the next version is ready to launch! wouldn’t it be great to be able to consolidate everything onto one or two servers, sell the others, and keep yourself in business a bit longer, until you can get version two out the door? If you designed your software and hardware with both kinds of scalability in mind, you might just stick around long enough to see version three.

So how does all this fit into Railspace? Well, first off, design your application so different bits can be spun out onto separate application servers. Perhaps even allow for logical breaks in the database. Tune your app to get as much bang for each buck as possible. Look at bottlenecks, both at a software, and hardware level. Know the difference between performance and scalability. Know that tuning your software helps with performance, but that scalability is what handles the digg effect. With this knowledge in place, you can be better equipped to handle all the traffic your heart can desire. Ruby on Rails is perfectly capable of handling anything that comes its way, but it does require planning, and work. Building a scalable architecture for Rails to sit on allows all the benefits to shine.

-Joe

This entry was posted on Wednesday, July 25th, 2007 at 11:32 pm and is filed under Design, Ramblings. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.