Specifications

22 | august 2008 www.linuxjournal.com
I am writing this article in mid-May 2008, several
weeks after Twitter was rumored to be moving to
a platform other than Ruby on Rails. Twitter, of
course, is an extremely popular service that allows
users to write updates and notes about their current
status—and allows readers to follow any number of
people’s Twitter feeds. You can think of Twitter as a
combination blogging and RSS platform, populated
by people who express themselves with only 140
characters at a time.
Like many other runaway Internet successes,
Twitter appears to have become too popular for
its own good. This has led to some outages, most
notably one at the beginning of 2008 that took
more than a day to restore. Thus, it was seen as
more than a mere coincidence when Twitter’s main
architect left the company, and that within a few
days, the TechCrunch blog was quoting anonymous
officials within Twitter about how the service would
be transitioning away from Ruby on Rails.
This was followed by a great deal of discussion
over whether Rails is a “scalable” architecture.
Scalable used to mean that it was possible to scale
up applications using a Web site, almost regardless
of how many people are using it. But today, a
scalable architecture is one that’s lean and mean,
handling as many users as possible with as few
servers as possible. PHP, Java and .NET are pretty
universally considered to be scalable in this sense.
Although even the most efficient PHP application
can handle only a finite number of simultaneous
users, it’s undeniable that Ruby is a slower lan-
guage than PHP, and that the Rails framework
adds some more overhead.
Of course, it’s one thing to say that Rails doesn’t
scale as quickly as PHP, and another to say that it
doesn’t scale at all. And, there are other arguments
to be made, including the fact that programmers
cost more than servers, and that programmer
productivity should be at least as significant a
factor as scalability.
That said, it’s easy for a Rails application to
become slow. So, it is nice to know that a variety of
utilities can be used to profile Rails applications—
meaning, finding out exactly which portion of
the program is taking a long time to execute. This
month, we look at some techniques for profiling
Rails applications. Although such profiling doesn’t
make the software run any faster, it can help identify
the slowest parts of an application.
Profiling Pages
If you aren’t happy with the performance of your
Web site—and quite frankly, you always should be
concerned about the performance, trying to give it
a boost wherever possible—the first question to ask
is, “Where are people spending their time?” After
all, if there are 100 different pages on your site, it
doesn’t really matter whether page 35 is really slow
if no one ever visits it.
The first tool to examine, the production log
analyzer, is designed to look at the Rails production
log and produce some basic statistics about it. The
production log, as well as the development and test
logs, are typically stored in the log directory under
the Rails project root. Thus, on a production server,
the log is in log/production.log. This logfile is not
rotated or modified automatically; there are clearly
a number of ways to do that using cron and other
UNIX command-line tools.
The thing is, there already is a facility on UNIX
(and Linux) systems for handling logfiles, including
their periodic rotation and disposal. This facility
is known as syslog, which makes it possible to
send logging information to a variety of different
files based on priorities and source materials. The
/var/log directory on my Ubuntu server is full of
different logfiles, and nearly all of them were
created and written to by syslog.
It turns out that we can use syslog for our
Rails production logs. Once we have done that—
and yes, we must use syslog for this to work—we
then can analyze our production logs, learning
exactly how much time people have spent in our
Rails application.
To move your Rails production log to syslog, you
need to do several things. First, you must install the
Ruby gem that provides this behavior:
gem install --remote SyslogLogger
This installs the gem in the appropriate place
Profiling Rails
Applications
Wondering if your Rails application is running at peak efficiency?
Before optimizing, profile your application to see which parts are slow.
AT THE FORGE
COLUMNS
REUVEN M. LERNER