
A few days ago I reconfigured my VPS to redirect (almost) all XML requests to FeedBurner. What a surprise to find out that I have 7,000 subscribers! I guess I’d better blog a little more often.
# Special config/virtual_hosts.conf for lighttpd
# Send nubyonrails feeds requests to FeedBurner
$HTTP["useragent"] !~ "FeedBurner" {
url.redirect = (
"/xml/(rss|rss20|atom|atom10)/feed.xml" => "http://feeds.feedburner.com/nubyonrails"
)
}
I love looking at statistics, and maybe you do, too. Here are a few.
In the pie chart above, you can see that the largest percentage of readers view my feed in the Google Reader. Netvibes trails close behind, which surprised me. I thought more developers would use desktop readers, but they don’t. NetNewsWire commands only 6% of subscribers.
A few months ago I wrote a script that used an Apache log parser to read my logfiles and count the number of RSS requests. Bloglines was way out ahead. Either people have switched to Google and Netvibes in the last 6 months, or my script was inaccurate (yes, it did take into account the metadata in feedbot requests that shows how many subscribers a request is being made on behalf of).
Personally, I stopped using an RSS reader of any kind about 6 months ago. I read Planet Ruby on Rails, Ruby Inside and my own PeepCode Network (powered by Peter Cooper’s FeedDigest). I rediscovered Hpricot (and HAML) last weekend and started a redesign of this site that will make it into the Ruby news portal that I want to read but doesn’t exist yet. Give me a few weeks.

Most people view this site from Windows. Shocking! Maybe the Rails community needs to treat our Windows-using friends a little more nicely?

Most people are using Firefox. Only 10% on IE, so Rails developers represent the complete opposite ratio of the general public.


These are the results for one day (instructions).
Before the redirect I was averaging about 80 requests per second. It turns out that most of that was due to very fast action caching for the XML feed (which made up 90% of the requests to this site). I’m still keeping it retro with Typo and it does a pretty good job of caching things when it can. However, the average took a bit of a hit when I dished off 90% of my requests to FeedBurner (the few remaining XML requests are for the comment feeds).
The reality is that the load on my machine is usually under 0.1, even with a few other sites and a Mint installation for PeepCode.
Finally, I apologize to all the students who reach this site via the 8th Google result for how to cheat on a test. I hope you learned something about test-driven development, even if by accident!

The Rails Analyzer Tools are a very useful way to keep tabs on the performance of your site. They were written by Eric Hodel and have been open-sourced to the community by the Robot Co-Op.
The problem is that you need to install and run SysLogLogger to make it work. If you have more than one Rails app on a box, or if you don’t have root access to the box, or if you are on a shared host, you are out of luck.
No longer!
gem install production_log_analyzer gem install rails_analyzer_tools
Download the logger replacement and put it in your lib directory. (I’ll make this into a proper plugin soon.)
In the Initializer section of environment.rb, add
require 'hodel_3000_compliant_logger' config.logger = Hodel3000CompliantLogger.new(config.log_path)
For some reason, the standard script/server forces logging to work the old way. If I run mongrel_rails start, it works fine. I’m also running a production app with mongrel and it works as expected.
If you tail -f log/development.log you should see something like this:
Jan 03 10:08:09 topfunky rails[4535]: Rendered shared/_menu (0.14430) Jan 03 10:08:09 topfunky rails[4535]: Rendered shared/_flashes (0.00882) Jan 03 10:08:09 topfunky rails[4535]: Completed in 1.70117 (0 reqs/sec) | Rendering: 1.61409 (94%) | DB: 0.02340 (1%) | 200 OK [http://localhost/products/capistrano-concepts]
Deploy your app, or just try this out locally from the command-line.
$ pl_analyze log/development.log
Request Times Summary: Count Avg Std Dev Min Max
ALL REQUESTS: 33 0.226 0.304 0.005 1.695
OrdersController#show: 6 0.071 0.112 0.005 0.316
ProductsController#show: 3 0.306 0.061 0.231 0.381
ProductsController#home: 2 0.318 0.068 0.249 0.386
OrdersController#index: 2 0.328 0.206 0.123 0.534
PagesController#show: 2 0.432 0.047 0.385 0.479
ProductsController#index: 1 0.279 0.000 0.279 0.279
Slowest Request Times:
OrdersController#index took 0.534s
PagesController#show took 0.479s
ProductsController#home took 0.386s
PagesController#show took 0.385s
ProductsController#show took 0.381s
# DB times and Render times follow
rails_stat is also nice for seeing a live report of the performance of your app.
$ rails_stat log/development.log ~ 0.9 req/sec, 14.2 queries/sec, 19.9 lines/sec ~ 0.3 req/sec, 14.1 queries/sec, 17.0 lines/sec
Run the report in a cron task and send the results to yourself via email (see the -e flag to pl_analyze), or automate the reporting with Capistrano.
desc "Analyze Rails Log instantaneously"
task :pl_analyze, :roles => :app do
run "pl_analyze #{shared_path}/log/#{rails_env}.log" do |ch, st, data|
print data
end
end
desc "Run rails_stat"
task :rails_stat, :roles => :app do
stream "rails_stat #{shared_path}/log/#{rails_env}.log"
end
For more details on Capistrano, buy the new PeepCode Capistrano Concepts screencast.
For extra credit, use my Mint Pepper plugin (download) and my Mint Rails Plugin to put nightly data into the database (also requires the setup of logrotate, to be discussed later).
Remember, this is not about maximum performance. These reports show you the actual performance of your app as it is being browsed, not the theoretical maximum performance.