Enterprise Rails

Speed Versus Scalability

It is true that Ruby, as a language, does execute software programs more slowly than some other programming languages. However, this is a red herring in the discussion of scaling websites, as speed and scalability are not equivalent. If the stuff of websites was real-time processing of complex data, then Ruby’s speed could be problematic. However, most websites don’t do much more per request than look up some information and display it, or otherwise accept some information and store it. The time required to process this type of task is fast no matter what language you choose.

On the other hand, once you start building up simultaneous requests, these requests will compete with each other, and requests will begin to appear slow to end users. In an ideal situation, you would simply add more hardware to restore your site to optimal performance levels. In fact, in an architecture designed for scaling, you should be able to add hardware in a linear fashion to handle any number of users imaginable.

This is where speed and scalability get confused. A language may be slow or fast, but it’s your architecture that is scalable or not. This pertains not just to your code itself—the algorithms and how you string together your syntax—but also on the edges of your applications, how they fit together, and the expectations and demands placed on different parts of the system. Are any spots likely to become bottlenecks or single points of failure? Can each piece improve its own ...