Open Source by FiveRuns

We congratulate the Merb team on a successful 1.0 release!

We’d like to announce a new version of the TuneUp panel slice gem for Merb (which sits up at GitHub), as well as the core TuneUp dependency.

v0.5.3 is a bugfix release, addressing issues with uploading runs and removing development dependencies that were causing loading issues. The installation instructions have also been updated, removing the now-unnecessary installation task (assets are now copied automatically on startup, as with the TuneUp for Rails) and changing the routing instructions.

Many thanks to Matt Aimonetti for his continued help tracking down issues and providing Merb slice “best practice” guidance. Cheers!

Last year, we launched a partnership with BitRock, an innovator in open source tools and stacks, and introduced FiveRuns Install, a Ruby on Rails stack optimized for production environments. Install has been a great success, with thousands of downloads from the community. This week, we’ve happy to announce that we’ve expanded our partnership with BitRock and now their BitNami RubyStack, a freely available, ready to run distribution of Ruby on Rails, will include FiveRuns TuneUp, our free/open source application profiling tool for Ruby on Rails and Merb developers.

The BitNami RubyStack was released in 2007 and has been downloaded tens of thousands of times. It’s a freely available, ready to run distribution of Ruby on Rails, packaged with BitRock’s multiplatform installer, making it easy to have an enterprise-ready Rails environment up and running in just a few minutes. By including FiveRuns TuneUp with the RubyStack, we wanted to give developers a complete environment for installing, developing, and profiling Ruby on Rails applications that can be optimized for performance and scale.

BitRock has been a terrific partner, and we’ve been continually impressed by their expertise and leadership in the open source stack business, so we’re very excited to further our relationship and offer up this bundle to the Rails development community. RubyStack is currently available for Linux, Mac OS X, and Windows, with support for Solaris coming soon. It is free to download and use under the terms of the Apache 2.0 license.

For more details, or to download a copy, visit BitNami.org.

TuneUp is FiveRuns’ open source plugin for profiling the performance your Rails and Merb applications. TuneUp is intended to be run locally in your development environment, since the instrumentation returns detailed analysis of a single browser invocation. Bottlenecks can be identified before deployment and before your users experience a performance issue.

Why?

There are some times it may be useful to run TuneUp in production. Perhaps you’d like to share the profiling view across a team. Maybe you’d like to compare the metrics of that same request, against your production database’s configuration, on the actual hardware or under the live platform’s operating system.

All you need to do to activate the TuneUp instrumentation in production is create the following file:

 /YOUR/APP/config/tuneup.rb  

Containing the following:

Fiveruns::Tuneup.config do |config|
    config.environments << :production
end

That’s it. Restart your rails app on the server and it will render the TuneUp instrumentation bar to your local browser. From there, you can toggle it on and off and profile the live server requests remotely.

Why not?

Running TuneUp in production should be done in a closed environment. The instrumentation bar, sequel queries, controller names and other analytics about the code base are displayed. Also, multiple browsers accessing the application concurrently may skew the profiling results.

If you’d like to permanently monitor your servers’ Rails performance in production, check out FiveRuns Manage.

I’ve been playing with benchmarking tools this week. After reviewing the open source options, I ended up working with just a few of the dozens of choices. Some are new and Rails specific. Some are no longer maintained yet remain popular choices. Here’s a sample:

• httperf
• Siege
• RailsBench
• ApacheBench
• Selenium
• Rails performance test generator

There are not only a lot of tools, there are a variety of approaches to take. Are you looking know how fast your application can return a single user’s transaction? Is a better durability test to know how much traffic your application can sustain over longer periods? Should you test individual pages of the web app or build workflow sequences to more closely simulate real world activity?

For your performance test method, what’s your choice of benchmarking tools?

So your shiny new Rails application is ready for production. Time to configure the server application layer. A common question we hear at FiveRuns is: What’s the best number of Mongrels to use? There are a plenty of opinions, including yours, so feel free to comment below.

Test Drive

Early on, Zed recommended performance testing with httperf and an increasing numbers of mongrels to determine the best number for your setup. Test a file served directly from the web server and then test your app via a single mongrel instance. This provides a static file reality check and then a decent baseline from which to improve the responsiveness based on additional mongrels.

> 1

Depending on the memory footprint of each mongrel process and the available system memory, you may have an upper limit to consider for your server. Some administrators use at least two mongrel processes to balance the queue and avoid any locking behind a single mongrel or Rails request. My tests with a very entry level 256 MB virtual machine yielded the best performance using 3 mongrel instances behind an Apache2 front end.

Us

The average number of mongrel processes used by our customers is 5 per Rails app and 12 per server on systems with 8 GB of physical memory. This is what we run here at FiveRuns too. For example, a common setup is to have two high volume applications, served by 5 mongrels each and a lower volume Rails app with 2 mongrels. A lightweight front end like nginx balances traffic among the mongrel ports in use and optionally, any additional application servers in the hardware pool.

None?

Choosing not to answer the “How many Mongrels?” question is becoming a popular option. Passenger handles the port management between the front end and application layer, including the optimal number of back end processes. Thin is lightweight and crazy easy to install and configure. Each yield comparable or better performance metrics. Ebb also lists significant performance gains over mongrel.

So with configuration ease and performance gains, why choose mongrel today? Still grateful for delivery from FastCGI/lighttpd? (like me?) Perhaps you are gauging the community adoption of the alternatives? Maybe it’s a proven part of your existing architecture?

Welcome to the second FiveRuns blog post to automate server configuration for Ruby on Rails. We received great feedback and suggestions about the original script, Automatic Rails at Slicehost, which installed the basics. This time we’ll use standards like Capistrano deployment, separate web and application layers and an active database backend. While the Hello World application surely dazzled your friends and family, this time we’ll take it up a notch and deploy a working, full stack community web application, Trevor Turk’s cool Rails app, Eldorado.

The What

This script connects to a new Ubuntu 8.04 server and configures all necessary applications and libraries. Since we are installing a lot more this time, it’s a bit long to post here, so I’ve linked to it on Github. You still only need to provide 2 pieces of information: the target address of your server and the password. Execute the script locally which downloads Eldorado, the associated configuration files and then connects to your server to push the installation.

• Ruby 1.8.6
  
• Rubygems 1.2
  
• Sqlite3
  
• MySQL 5.0.51a
  
• Thin 0.8.2
  
• Hello World example Rails application
  

• nginx 0.5.33
• Mongrel 1.1.5
• Eldorado Rails application
• Capistrano deployment
• Rubygems 1.3

The How

1. Download the script from Github. I’ve abbreviated the URL.

wget http://tinyurl.com/57sjce -O configure_ubuntu_eldorado.sh

2. Run the script.

sh configure_ubuntu_eldorado.sh

That’s it! You’ll be asked for your password twice, once to set up the OS via ssh and once to run the Capistrano deployment tasks. Speaking of passwords, best practices include dedicated deployment and MySQL user accounts. This script uses the root account for simplicity.

The Why

The script originated as a DRY effort for Slicehost deployments. You can now point it at other providers, remote Ubuntu servers or virtual machines. It’s become a handy way to explore a working Rails environment without manually installing every component. Also, writing configuration automation is a great way to hone your deployment skills. Thanks go to Trotter Cashion for the suggestion to maintain the scripts on Github, where they’ve been forked and extended. Check out Jørgen Orehøj Erichsen’s blog adding support for Passenger and Ruby Enterprise Edition.

All the scripts and configuration files are on Github so feel free to post any feedback or suggestions.

We’re proud to release version 0.5.2 of TuneUp for Merb. This release fixes one bug, which was the incorrect display of TuneUp in Safari.

Here’s how to update:

• gem update fiveruns_tuneup_merb
• in your merb app run rake slices:fiveruns_tuneup_merb:copy_assets

Enjoy!

Since TuneUp was released in May, we’ve been thrilled by the interest we’ve seen from across the Ruby community. It’s become a day-to-day debugging, performance tuning, and communication tool for many Rails developers, and over the last few months the involvement of the community in improving the stability and usability of the plugin as an open source project, hosted on GitHub, has been tremendous. Thanks, everyone!

So, what’s next for TuneUp?

Over the last year or so the Ruby community has seen an explosion of new web frameworks. We all love Rails, but a little friendly competition is a good thing, right? At FiveRuns we’re first and foremost Rubyists, and we’ve been having a lot of fun playing with these alternatives and thinking about how we can support them in our products.

We’ve been especially interested in Merb, which has been steadily growing in popularity and stability, and has popped up in feature requests from our customers. We’ve talked to a number of shops that include Merb development in their bag of tricks, and support for Merb in TuneUp has been a frequent follow-up question after demos at Ruby user groups.

So, today we’re announcing FiveRuns TuneUp for Merb, direct from MerbCamp in San Diego and just in time for the official release of Merb 1.0.

Let’s take a peek.

TuneUp for Merb is packaged as a Merb Slice, and works with Merb v0.9.5 and higher (it might even work with previous versions). Installation and setup is easy (we love slices); in just a few steps you’ll see a panel above your application that will provide in-depth information on the current action.

Currently, TuneUp for Merb provides information on filters, renders, and DataMapper activity (let us know what other ORMs you’d like to see. Sequel? ActiveRecord?). You can see what proportion of time you’re spending in the model, view, or controller, as well as how long each step takes to execute, where it’s being called (with support to jump to those files in TextMate), and for DataMapper activity the SQL query that was executed and a detailed breakdown of the Query object. Even if you’re not focused on performance, the TuneUp panel is a powerful exploratory tool; as with the Rails version, we expect we’ll hear developers are using it for debugging just as often as they use it for tuning.

The TuneUp Community

Another thing about TuneUp that we’ve received a lot of great feedback on is its use as a communication tool. With a single click from the panel you can send up the same detailed information on an action to http://tuneup.fiveruns.com, where you can keep it private (just to save it), share it with specific people, or even make it public—where the entire community can help you solve problems.

How do I get it and install it?

Installation is easy – in just a few steps you can start seeing detailed performance metrics on your Merb app. It comes packaged as the fiveruns_tuneup_merb gem. The detailed instructions are on the TuneUp web site.

Once configured, you can instrument your local Merb applications with TuneUp. For further capabilities, like uploading and sharing of TuneUp runs via the TuneUp website, please create an account and add the API key from your profile page. Please help us grow the public TuneUp community by uploading runs, sharing them and participating in the discussions.

Open Source

Our commitment to open source is the same as always. GitHub is a fantastic service, and we’re happy to make fiveruns_tuneup_merb (and dependency fiveruns_tuneup_core) available for forking. The project is still in its infancy, is most certainly a beta, and any help you can provide on making it more stable by contributing code (or sending bug reports and feature requests to our support team at ) would be greatly appreciated.

We’ve just unleashed FiveRuns TuneUp v0.8.17. This release fixes an issue when running on JRuby. It also corrects a snafu I introduced by building 0.8.16 against a modified working copy. My bad! If you were previously getting an exception coming out of _data.html.erb, this release should fix that.

The moral of the story is, you should always run git status or svn status before you build a Gem!

This article details the scripted configuration of a Slicehost VPS for serving production Rails applications. Working with the FiveRuns team, it’s been valuable to deploy and redeploy a pristine Rails server environment quickly. This allows testing, debugging and simulating customer environments.

There are some great tutorials covering the step by step configuration of Ruby and Rails and Passenger at Slicehost. The main difference of this article is the script is self contained and does not require any user input except the password of your target slice. We’ll take your environment from blank build to live, serving a sample “Hello World” application in about 90 seconds.

The default root credentials are required for the initial connection to a new Slicehost slice. The setup script will run during that connection. After it completes and for production uses, the credentials should be updated and administrative, non-root accounts added. I chose Ubuntu 8.04 and its excellent package management to keep the configuration steps concise and convenient. Why not run this script directly on the server vs. passing it via ssh? You can. Executing remotely persists the script for easy repointing later or to multiple slice targets. Also, you can deploy other Rails applications from your local repositories using your Capistrano scripts.

Ubuntu’s apt-get packages can be dated, so feel free to substitute a more current version of any of these. I did this for the rubygems install to avoid the index update process of version 0.9.4 The steps to compile a specific version of Ruby is available in a previous blog post by Oliver. The packages and libraries installed are:

Ruby 1.8.6
Rubygems 1.2
Rails 2.1.0
Sqlite3
MySQL 5.0.51a
Thin 0.8.2

That’s it! I’ll add automation of more complex Rails apps and other Linux distros soon. Let me know if you have any requests.

#    This script will remotely configure your Slicehost VPS with the necessary applications and libraries
#    to serve and monitor a production Ruby on Rails application.  A simple "Hello World" Rails
#    Application is installed and started to confirm the process.
#  
#    Versions installed are Ruby 1.8.6, Rubygems 1.2, Rails 2.1.0. Sqlite3, MySQL 5.0.51a, Thin 0.8.2

#    Make remote ssh connection   (substitue your target server's address)
#  
ssh root@fiveruns.slicehost.com '

#    Update Ubuntu package manager
#
apt-get update
apt-get upgrade -y

#    Install dependencies
#
apt-get -y install build-essential libssl-dev libreadline5-dev zlib1g-dev  
apt-get -y install libsqlite-dev libsqlite3-ruby libsqlite3-dev 
apt-get -y install mysql-server libmysqlclient15-dev mysql-client 

#    Install Ruby 
#
apt-get -y install ruby ruby1.8-dev irb ri rdoc libopenssl-ruby1.8 

#    Install rubygems v.1.2 from source.  apt-get installs
#    version 0.9.4 requiring a lengthy rubygems update
RUBYGEMS="rubygems-1.2.0"
wget http://rubyforge.org/frs/download.php/38646/$RUBYGEMS.tgz
tar xzf $RUBYGEMS.tgz
cd $RUBYGEMS
ruby setup.rb
cd ..
ln -s /usr/bin/gem1.8 /usr/bin/gem

#    Install gems
# 
gem install -v=2.1.0 rails --no-rdoc --no-ri  
gem install mysql  --no-rdoc --no-ri
gem install tzinfo mysql thin --no-rdoc --no-ri

#    Configure a simple Rails Application
#
mkdir /var/www/
cd /var/www
rails hello
cd hello
./script/generate controller welcome hello
echo "Hello World" > app/views/welcome/hello.html.erb

#    Download FiveRuns Manage  ** Installation and registration is run seperately **
#    If you are new to FiveRuns, sign up for a free trial:  https://manage.fiveruns.com/signup
#    After, you have created an account, just execute the installer that is downloaded here
#
cd /tmp
wget http://manage.fiveruns.com/system/downloads/client/manage-installer-linux-ubuntu-64bit-intel.sh

#    Install the Manage gem and echoe gem dependency
#
gem install fiveruns_manage --source http://gems.fiveruns.com
gem install echoe --no-ri --no-rdoc

#    Install, configure and start the Thin web server
#
thin install
/usr/sbin/update-rc.d -f thin defaults
thin -p 80 config -C /etc/thin/hello.yml -c /var/www/hello
/etc/init.d/thin start
'

On the 9th, I had an opportunity to speak to Boston.rb about Ruby 1.9. Ruby 1.9.1, a stable release, is due out this December, and the changes from Ruby 1.8.6, the production Ruby of choice, are fairly significant. My talk was focused on the new syntax and language features, and covered a number of “gotchas” that could trip-up the unwary.

I spoke at the Lone Star Ruby Conference a few days prior on the same subject, but my Boston talk was geared for a smaller, more interactive setting.

The Boston group was fantastic; a nice mix of skill levels, good commercial interest in the language in the area—and the venue, Sermo, was definitely one of the best catered meetings I’ve ever attended! My thanks to everyone at Boston.rb (especially Josh) and the guys at Thoughtbot, who put me up, let me hang out at their office, and showed me the sights.

We are proud to release FiveRuns TuneUp v0.8.15.

This release fixes the issue that users have been having related to the TuneUp panel appearing, but no data showing up.

For the curious, this bug seems to appear when used TuneUp is used alongside plugins that alter Rails’ javascript generator (like jrails). We removed all javascript generator usage from TuneUp to prevent this bug from occurring. We want to extend a hearty thanks to Chris Zelenak for leading us in the right direction towards a bugfix by providing reproduction steps and a sample Rails app that demonstrated the bug.

This version is recommended for all new and existing TuneUp users.

Like most servers, Apache allows you to capture details about its performance and status. These metrics are not published by default however and can be tricky to configure securely, especially in an environment using virtual hosts. This article describes how to configure Apache2 to enable its server-status statistics which can be viewed directly via web browser or collected by monitoring tools such as FiveRuns Manage. Additional metrics are published by enabling ExtendedStatus which we will also enable.

In its simplest implementation, there are just a few steps to enable Apache’s mod_status. In the Apache2 configuration file, (often: /etc/apache2/apache2.conf for Apache2 and /etc/httpd/conf/http.conf for Apache v.1.x) this is enabled by adding or uncommenting the following lines:

LoadModule status_module  libexec/apache2/mod_status.so 
ExtendedStatus On

<Location /server-status>
     SetHandler server-status
     order deny,allow
     deny from all
     allow from 127.0.0.1
</Location>

The above edits and a restart of Apache will publish the status metrics to clients on the local system. As in the Apache.org example, security can be lowered to allow remote clients access the server statistics. Since that can be a security concern and because monitoring tools can be installed locally, our examples restrict access to the local web server.

One challenge we often encounter is Apache environments using virtual hosts. The <Location /server-status> directive needs to either appear in the parent apache.conf/http.conf file or in the virtual host that is loaded first. When multiple .conf files are loaded via the Include directive, it is done alphabetically, so consider this when inserting the server-status Location block.

Alternately, you could dedicate a virtual host to serve the status information and bypass the load ordering issue above. The example below details a NameVirtualHost configuration utilizing the localhost hostname. A similar approach could be used to dedicate a vhost using IP-based Virtual Hosts and 127.0.0.1.

<VirtualHost *:80>
  ServerName localhost
  ServerAlias 127.0.0.1
  DocumentRoot /var/www/

  <Location />
     order deny,allow
     deny from all
     allow from 127.0.0.1
  </Location>

  <Location /server-status>
     SetHandler server-status
     order deny,allow
     deny from all
     allow from 127.0.0.1
  </Location>

  <Directory /var/www/>
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>

</VirtualHost>

Hot on the heels of the ‘Run Your Way to RailsConf Europe’ contest announcement, we’ve released version 0.8.11 of FiveRuns TuneUp. Since our last publicly-announced release, we’ve made a few substantial fixes and improvements. Most notably, these include:

• Signup and login for the TuneUp service is now only required if you want to share a run. If you just want to use TuneUp locally for your own personal development, you don’t need to sign up at all. If, however, you decide that you’d like to use the (free) TuneUp service to share your runs with colleagues or the Rails community, registration is simple.
• Instrumentation for partial rendering under Rails 2.1 now works properly.
• Fixed some lingering issues with XHTML Strict 1.0 compliance.

Grab the latest gem and get to tuning up your Rails application!

One of the lingering issues we’ve had to deal with over the last year in the Manage service is ActiveRecord’s reluctance to talk to more than one database. It’s really quite stubborn in that regard and while there are a few solutions out there, none of them worked quite like we wanted. Some required intrusive application-level code changes, some didn’t offer the features we needed, so we bit the bullet and wrote what we needed.

Specifically we needed two features to scale our mysql database: application-level sharding and master/slave replication. Sharding is the process of splitting a dataset across many independent databases. This often happens based on geographical region (e.g. craigslist) or user account (e.g. flickr). Replication provides a near-real-time copy of a database which can be used for fault tolerance and to reduce load on the master node. Combined, you get a scalable database solution which does not require huge hardware to scale to huge volumes. DataFabric extends ActiveRecord’s standard connection handling to provide these two features.

To install, invoke the usual magic:

gem install data_fabric

Add DataFabric to your Rails 2.1 gems listing in config/environment.rb:

config.gem "data_fabric"

Annotate your sharded models with your desired sharding and replication setup:

class Auction < ActiveRecord::Base
  data_fabric :shard_by => :city, :replicated => true

Let’s assume we are sharding based on the city associated with the request (i.e. the Craigslist model). You’ll need to add the necessary database connections to your config/database.yml for each city based on the naming convention DataFabric uses. See the README for details.

Finally your application controller will activate the city’s shard for each request:

class ApplicationController < ActionController::Base
  around_filter :select_shard

  private
  def select_shard(&block)
    DataFabric.activate_shard(:city => @current_city, &block)
  end
end

Now, whenever you do anything with the Auction model, it will only affect the current shard. Auction.find(:all) will find all auctions within that shard. The converse is also true: you can’t do anything with the Auction model until you set a shard. Note that you can just set the replicated flag without the shard_by flag; DataFabric will act just like Rick Olson’s Masochism plugin.

We’re releasing DataFabric on github for others to use as they see fit. Take a look at the README on github for technical details and code samples. We’ve used it successfully with ActiveRecord 2.0.2 and 2.1. There are some areas which can be painful to deal with, notably migrations and fixtures, but we have both working in production here so you can overcome. :-) I’ll give you a hint: the example application might help.

Good luck and let us know what you think!