Pinderkent

When it comes to purchasing consumer-grade PCs these days, it's rare to find a system with a CPU that only has a single core. Most laptops even offer a dual-core CPU. So as software developers, we're entering a unique era where we can start to employ parallelism in ways that would not have been practical before. In some cases, we will need to exploit this parallelism if we hope to increase the performance of our software.

Unfortunately, we are also seeing a move towards the development and use of Web-based applications. These are applications that are hosted on a remote server, and provide an HTML- and AJAX-based interface that is accessed via a Web browser.

These Web browsers attempt to give us some degree of parallelism, often through tabbed browsing. While this works great for relatively static content, we experience problems with JavaScript scripts that run for anything longer than 500 ms or so. Since the computation of all of the tabs is performed within the same (main) thread of the browser, a long-running JavaScript script immediately locks up all of the other tabs.

The solution is quite clear: each browser tab should have its own thread, in which a separate instance of a JavaScript interpreter executes. A long-running JavaScript script in one tab (ie. one that runs for 2 to 3 seconds, if not more) will not prevent, at the very least, the user from switching to an alternate tab and continuing to work there.

Of course, most Web browsers today just aren't prepared for such an architectural change. And considering how large of a job it is to write a high-quality browser, it seems unlikely that we'll see a Web browser written from the ground up that better supports the benefits offered by the now-prevalent multi-core CPUs. So it's quite unfortunate that we have all of this processing power available to us, but it can only be exploited to a limited degree because developers are choosing to write JavaScript-based applications that execute within parallelism-unfriendly Web browsers.

As most people involved with Web development know, Ruby on Rails 2.0 was released on December 7. There was some discussion about the release on Slashdot, where I noticed some interesting comments regarding scalability in the age of Ruby on Rails.

I found this one comment in particular to be worthy of further examination. The comment author describes an online game he or she had implemented using Ruby on Rails, and stated, "It's running of a single dedicated server and it seems to be handling a lot of requests just fine. During peak periods, we've got multiple requests per second and I've never had any complaints about the performance."

Given the massive amount of processing power offered by even a low-end consumer PC today, nevermind a server-oriented system, there's absolutely no reason why a Web site should not be able to handle "multiple requests per second".

About a decade ago, I developed a number of Perl CGI scripts for one Web site. At peak times, they were getting upwards of 50000 hits per hour. That's about 14 hits per second. But the interesting thing is, they were serving their site off of two high-end SPARCstation 20 systems. For those unfamiliar with such systems, in terms of processing power they're comparable to a typical PC from 2000 or 2001. One of the SPARCstations ran the database server, the other ran the Web server and the CGI scripts. During the time I was affiliated with them, scalability was never an issue. And this was with a limited amount of caching, distributed processing, and other scalability techniques that have become more important.

If a scripting language like Perl was suitable for developing highly-utilized Web sites a decade ago on hardware that was already a few years old, there's no reason why Ruby on Rails shouldn't be able to handle "multiple requests per second" on modern hardware.