Pinderkent

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.

I'm a staunch supporter of putting old, but working, computers to good use again. Personally, I have repurposed numerous systems back into production after they were deemed to be too old, and replaced with newer hardware. One of my favorite tools for enabling this is NetBSD. As described on the NetBSD Web site, "NetBSD is a free, secure, and highly portable Unix-like Open Source operating system available for many platforms, from large-scale server systems to powerful desktop systems to handheld and embedded devices."

At the pub last night, a friend of mine who also does some IT work was telling me of how he rescued three old 200 MHz PCs with the help of NetBSD. He works for a Web site operator, and part of their operations involve serving copious amounts of images. So he installed NetBSD on those systems, and ran some stress tests over night. The next morning he set up Lighttpd, and within a couple of hours they'd been integrated into the network and were serving images.

He was sort of surprised that they were able to handle the load so well. But it's really not all that surprising. A typical PC with a 200 MHz x86 CPU is actually quite powerful. And for a task like serving images, it is more than suitable. Using efficient and effective software like NetBSD and Lighttpd makes it ever more useful.

Jomo Fisher wrote recently, suggesting that symmetric multicore processors are a "dead end". In turn, an architecture involving one fast processor and many "slave" processors is suggested. But this really isn't a novel idea by any means. The Cell microprocessor, developed by IBM, Sony and Toshiba, is quite similar in many ways. Not only that, but it already exists, and is being used commercially (including the PlayStation 3 console).

The Cell BE architecture combines eight Synergistic Processing Elements (SPEs) with a Power-based PPE. Each SPE has a local register file. The EIB, or Element Interconnect Bus, is used to efficiently connect the various units of the CPU.

This this is quite similar to what Jomo is proposing, with one high-performance general-purpose processor, combined with many helper processors, each which is relatively independent.

Today I read this prediction that mobile phone game developers will start to create JavaScript-based games, rather than using J2ME. This is partially due to the iPhone, but also because of Motorola's MOTOMAGX.

I have to say, this is quite unfortunate. JavaScript-based games running in the Web browser have proven, in my experience, to be quite terrible. This is something that I have written about recently. First was my terrible experience trying to play Brickslayer, a JavaScript-based Breakout clone. The I had yet another pathetic experience playing a JavaScript and SVG-based Space Invaders clone.

In both cases, the games were essentially unplayable. And they were tried on fairly powerful PCs, running modern versions of the popular browsers. When a JavaScript-based game crawls when running on a system with a 2800 MHz x86 CPU, I hate to think how terrible it would be on an embedded system with a mere fraction of that computing power.

Now, the article suggests that the Web 2.0-based environment is suitable for non-action games. That very well may be the case. But I don't think we should expect it to be able to do anything beyond that, at least not without some massive changes. It's apparently difficult enough to implement even low-quality clones of 30-year-old arcade games using JavaScript and the browser. Action games would seem to be a dream that is years off.

Thanks to an article on DesktopLinux.com, I was reading about the Asus Eee PC 701 system. One interesting thing about this system is that it will reportedly run a variant of Xandros Desktop Linux.

The article goes on to note that this device will apparently have 512 MB of RAM. It's the paragraph following that portion of the article that I find most interesting: While this may not sound like enough RAM to run Xandros, this Linux operating system is well-known for its ability to run with a bare minimum of RAM. In a DesktopLinux.com review in 2006, we were able to run the latest version, Xandros Desktop 4.0, on a far less powerful system: a 6-year-old Compaq Deskpro EN Desktop with a 500MHz Pentium III processor, 128MB of RAM and a 10GB hard drive.

I find it laughable that 128 MB of RAM is considered "a bare minimum" today. It's actually a very large amount of RAM. Back in the 1980s and even into the late 1990s, those of us in the corporate world would have been amazed to have that much RAM at our disposal. At one job, we used a Sun SPARCstation 1 with 1 MB of RAM. This was around 1991 or 1992. On this system, we ran not only a fairly busy email server, but also a couple of databases and several other backend applications. Looking back, I don't know how we got by with such a system. Perhaps software was written with more care in those days. Regardless, we had some of the older system administrators telling us how lucky we were to have 1 MB. They recalled the days when 64 KB of RAM was considered a lot.

When it comes to desktop systems, there's absolutely no legitimate reason why a capable desktop system needs more than 128 MB of RAM. In the early 1990s we had NeXTstation systems that worked comfortably with 12 MB of RAM. Keep in mind that these systems came with a very capable suite of desktop software, still comparable in many ways to Mac OS X today. And even then, we were dealing with relatively heavy-weight technologies like Objective-C, Display PostScript, Mach, and so forth. Yet those systems still performed very well, with 100 times less RAM than the typical low-end consumer PC today!