(from American Scientist magazine, Mar-Apr 2008)

Previously Science and wayneseguin published a study looking at the performance of nginx fair proxy. To take that a little further, Science conducted an examination of how Thin and Mongrel compare head-to-head on performance. For kicks we took a look at Rails page template caching facility to see if that significantly impacts performance (it does). Full details follow..

For an idea of what the h/w testing setup looked like, read the previous study (cited above). For these tests, we used 3 instances of Thin or Mongrel (with lots of free ram). nginx fair proxy was turned on. Rails caching was fully enabled (including template caching). The tests all ran for 300 seconds. We pulled HEAD requests only to minimize over the wire throughput variance (since the test were initiated remote of the data center). Thins were wired up to unix sockets and Mongrels were going over IP.

Overall, I’d say that under these testing conditions Thin is 4% faster than Mongrel. That’s not much, and it’s within the standard deviation of each test result, but it was pretty consistent throughout the testing so I’m inclined to believe it. Your results may vary. [1]

Here is the summary of results:

The full test results (including Standard Deviations) can be found here. We hope the provided measurements meet your requirements. Post a comment here if you’d like more information or background.

1. While I thought that much of the performance improvements could be attributed to the unix sockets themselves, many knowledgeable folks including Zed (author of Mongrel) and Marc (author of Thin) assert that performance of IP vs Sockets is really marginal in this day and age. Both Zed and Marc have indicated that any performance differences are probably due to code and architecture differences in the app servers themselves.
2. You may also find this study of performance of various ruby app servers interesting: http://wiki.codemongers.com/Main
3. Science also has a writeup on optimizing Nginx and Rails page caching which may be of interest to readers.

• Zed Shaw requested a methodology review. The following bullets outline how I conducted all the tests.
• I used Jakarta JMeter 2.3.1 to run the test.
• I pulled HEAD requests to minimize measurement errors that might be caused by over the wire variations in bandwidth
• Rails Code path:
  • I ran against two fairly distinct code paths and had several hundred URL variations that hit all over the database within those two code paths (One code path searched for a set of records within a US state, the other searched for a specific record and displayed details about it).
  • Rails code used was production scale and quality. By this I mean it is code that runs a full-fledged webserver and it does a lot of work. It may not be the smartest or fastest code, but it provides a lot of user functionality that is probably pretty typical for “read mostly” Rails sites.
  • All activity was read-only - no insert/updates were performed. Simulated traffic was typical for this website.
• I had a warmup period before each test, to make sure that all core code was cached before running the actual test. Warmup was generally around 100 seconds. I was not precise on this though.
• Tests all ran for 300 seconds. There was a ramp-up period (to go from 0 threads running to all threads running) on each test that was equal in seconds to half the number of threads - so a 10 thread test had a 5 second ramp-up. A 30 thread test had a 15 sec ramp-up.
• Testing was run from a single dev workstation located on a 6mbs ADSL line (uplink is usually around 600kbs effective).

By science & wayneeseguin

Thin a new-ish application server, primarily designed for serving the same community as Zed Shaw’s (and now community managed) masterwork Mongrel. Its job is to dispatch web requests, primarily Rails and other Ruby frameworks. There’s plenty already written about Thin, to get you up and running.

I’ve been eying Thin and thanks to Wayne, I got motivated to test it out. He and I spent the better part of a day doing configuration analysis and performance testing on Thin in the context of EngineYard’s hosting environment. We had access to a brand new, unloaded “slice” (aka web server) on their server farm. The stack we used looks like:

Load balancers => Nginx => unix sockets => Thin => Rails

We ran a quite a few performance tests against Thin using the above setup and overall liked what we saw.

Summary:

• It’s stable - no crashing even with high concurrency
• It’s fast - performance was impressive (we will get some comparisons to Mongrel for you soon)
• It doesn’t use much memory - We think this is at least partly because it lets you use unix sockets instead of ip ports.

We went a little deeper too. In particular, because Thin is using epoll/event_machine to pull from the unix sockets, we were worried that while network performance would be improved, user-interface latency would rise because fast requests would get stuck behind slow requests inside the unix socket queuing mechanism. [2]

Nginx offers a way out of this problem in the form of its “fair proxy” module - it ensures that each request is sent to a socket only if that socket is not currently handling any work. So sockets are not allowed to queue - nginx does that. Wayne and I both have experience with nginx + fair with mongrels. So how would nginx + fair do with Thin? About as expected which is pretty darn well.

Wayne and I hypothesized that the fair proxy module would result in higher latency but lower “worst case” performance. In fact “max time to return” was faster in all cases for the fair proxy. But “90% of requests” were returned slower for fair. (Both were within one standard deviation but appear significant to my eye b/c we got the same pattern for each set of tests). Average performance was statistically identical in all cases as were the total number of requests made in 300 seconds.

1. You can see our raw performance data here.
2. To understand why this might occur, think of a rental car return area at an airport. They have long parking lanes, where you queue up behind cars in front of you waiting to return. Now if there’s a guy at the start of the lanes and he directs into a lane based on a round-robin strategy, if you get stuck behind a slow customer, two or three cars will pass you by in other lanes. That will make you annoyed. On the web you can’t see the other customers passing you, but queuing into sockets using round-robin can lead someone who has a lightweight request to wait behind a somewhat slower request. Unless your peak latency is under 1s, then this will cause noticeable problems for your customers.
3. Science also has a writeup on optimizing Nginx and Rails page caching which may be of interest to readers.

There may be much easier ways to do this but Science wrote a nice little regular expression which will convert your numbers to comma delimited strings in pure Ruby. It demonstrates some cool features of Ruby from which maybe you will learn!

def comma_numbers(number, delimiter = ',')
  number.to_s.reverse.gsub(%r{([0-9]{3}(?=([0-9])))}, “\\1#{delimiter}”).reverse
end
# here are some examples:
puts comma_numbers(1000)
# “1,000″
puts comma_numbers(123456.78)
# “123,456.78″
puts comma_numbers(”$12345″)
# “$12,345″
puts comma_numbers(”123456″, “.”)
# “123.456″ # Euro-friendly!

Let’s take a look at how this thing works. There are a couple of items that are worth examining in a little detail..

Firstly, since Regex operates left to right but we want to sub out numbers from right to left, we first reverse the string, which is super easy with a Ruby string.

Secondly, we create a regex pattern that does something interesting. We want to match and replace any three numbers which have a number in front of them with those same three numbers plus a comma. The interesting bit is that if we aren’t careful when we match the number in front of our three numbers, we will “advance the search pointer” inside regex past that value. This will result in our search being “off by one” - creating conversions such as “1,1234,000″

To understand why, first remember that the string is reversed when we regex it: “0004321″ Next, consider that the “4″ in the above example - it will be matched by a regex of %{([0-9]{3})[0-9]} We need to reference it to ensure that commas are only placed when there is a number in front of our block of three numbers..

But we want to search that 4 “again” after a match is made by gsub, so it can be counted as the group of three digits”234″ to be comma’ed. So we use a nice little Ruby extension to regex (?=[x]) which lets you match something in a repeated regex but keep the search from considering it matched for future matches. This yields the regex of %r{([0-9]{3}(?=([0-9])))} - some of those parens are extraneous but it’s easier for Science to read it that way (and future legibility of regex is one of its crucial failings). Happy commas!

A couple of great blog posts have come out in the last year, dealing with how to squeeze more performance out of Ruby on Rails. These techniques are actually massively improving the performance of Ruby on Rails, so much so that I’m starting to think of Rails less as an Application Framework and more as an Web Page Template Generator.

For background here are two of the best articles on using page caching, nginx and SSI to radically improve performance on Rails while sacrificing nothing:

http://theexciter.com/articles/dynamic-page-caching-with-nginx-ssi

http://blog.kovyrin.net/2007/08/05/using-nginx-ssi…

These techniques are great. They apply to you if your application:

1) Generates lots of pages with unique URL’s and each such page is accessed over and over.

1.a) For example, your site might have a single action which displays information about various regions around the country. It’s a single action which pulls from a database to generate info about Hawaii or the Gulf Coast, FL. Your URL’s look like:

/region/info/Gulf-Coast-Florida

/region/info/Hawaii

2) Each page is relatively slow (> 2s?) and resource consuming to build but doesn’t change all that often. You might assemble this region info from ActiveResources and XML feeds and what not, but once you’ve assembled the content on the page it might be valid for weeks or months.

3) Each page has some amount of dynamic content that prevents you from using page caching.

3.a) Each page might have a “login” link, or if the user is logged in it might be a link to their account saying “Welcome back Science! (account)”

In the traditional Rails model, you might just live with a 4s load time and move on with other projects. But with nginx SSI and page caching you don’t have to. You can build the dynamic content as a partial (like an Ajax request which returns an HTML partial). The rest of the page you build as fully page cached to disk or memcache. Nginx reads your SSI tag and calls back to Rails for only the very lightweight frequently changing dynamic content to assemble the entire page.

That’s pretty cool and the other articles cover this much in greater detail and clarify. Read up!

Science has been working on extending this work ever so slightly. What if your actions are CRUD and not only do they generate the above slowly changing dynamic content for GET requests but they also generate variable search results for form POST’s or AJAX requests (or WSDL or whatever): they behave differently, yielding alternative content depending on the CRUD or request method.

In the caching model above, you’re out of luck. Your nginx server is going to happily serve out your static page to all requests no matter what. A form or ajax post will simply yield the full page content just like before.

One way to solve this is to change your URL’s so that the request method is parsable on the command line:

/ajax/region/info/Hawaii

/post/region/info/Hawaii

But that kind of blows huh?

Another way to handle this is much more in the spirit of CRUD: Configure Nginx to by-pass POST requests and only serve the static page caches on GET requests. This makes perfect sense from an HTTP perspective: GET’s are cachable and POST’s reflect dynamic data. Perfect distinction. Since Ajax sends (generally speaking) its requests as POST’s everything fits together.

So get out there and add code to nginx to force it to skip page caching for POST’s. Here’s some snippets from my nginx.conf to give an idea of one way to solve this problem:

# rewrite any trailing "/" without the trailing "/"
# this is a work around - we must force nginx to treat pages with trailing slashes
# exactly like pages without them, so the page cache detection works correctly below
rewrite ^/(.*)/$ /$1 last;

location / {
  # turn ssi capability on
  ssi on;
  proxy_set_header  X-Real-IP  $remote_addr;
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $http_host;
  proxy_redirect false;
  proxy_max_temp_file_size 0;

  location ~ ^/(images|javascripts|stylesheets)/ {
    expires 10y;
  }

  # don't page cache any POST requests
  if ($request_method = POST) {
    proxy_pass http://mongrel;
    break;
  }

  # if we find the cached file on disk now (i.e. it's a GET request) serve it
  if (-f $request_filename.html) {
    rewrite (.*) $1.html break;
  }

  # if we find index.html version of request in root of website, it's also a cached file so serve it
  set $index 'index.html';
  if (-f $request_filename$index) {
    rewrite (.*) $1$index break;
  }
  # if we find index.html files anywhere else, serve as cached
  if (-f $request_filename/$index) {
    rewrite (.*) $1/$index break;
  }
  # otherwise if we don't find the file on disk, hand it off to mongrel/Rails to process
  if (!-f $request_filename) {
    proxy_pass http://mongrel;
    break;
  }
}

Science releases MojoMagick, an Ruby language image library “that does very little” ™. There are several useful image tools that “do a lot” - MojoMagick is designed to just a few things:

• Be fast
• Don’t leak memory
• Make simple ImageMagick tasks, simple as Ruby tasks
• Permit direct access to ImageMagick for complex tasks (i.e. get out of your way)
• Provide a central access to ImageMagick for good code architecture
• Easy to extend
• Limit memory accessible to ImageMagick (where desired)

That’s what it does. It’s packaged as a Rails plugin, but does not require Rails to run. If there’s any interest, I’ll make it a gem (just ask).

You can download a copy by following the instructions here.

Passing multiple arguments in Ruby is easy. You can pass any number of arguments, and even vary the class/types according to context. You can even vary the number of arguments passed. The receiver has to deal with this somehow, but even that’s pretty easy to manage. It’s a little trickier if the receiver has to delegate an unknown number of arguments to another receiver, but the * does the job for you - a great example of Ruby syntax that works for you. What follows is some simple example code to illustrate the idea.

def my_method(*args)
  # this line unrolls all the arguments out of the array
  # otherwise you'd be passing in an array to sub_method (see below)
  sub_method(*args)
  # here we don't unroll the arguments so you can see the receiver
  # just gets an array instead of a series of arguments
  sub_method(args)
end

def sub_method(*args)
  puts "Arguments received by sub_method as an array:"
  args.each do |arg_item|
    puts arg_item.inspect
    puts arg_item.class.inspect
  end
end

my_method('1','2',3,[4,5,6])

Output is:

Arguments received by sub_method as an array:
"1"
String
"2"
String
3
Fixnum
[4, 5, 6]
Array
Arguments received by sub_method as an array:
["1", "2", 3, [4, 5, 6]]
Array

A larger world exists, but we have never looked at it. We are too concerned with our microscopes or our magnifying glasses. We try to make things large by using magnifying glasses—but we have never looked at outer space with our naked eyes. If we looked into it, we could find it—but we don’t have to use our binoculars and telescopes. We don’t need them, they are false pretenses. We don’t need any means to do this; we could just simply look at it, whatever it is, and enjoy it. An immensely larger version of thinking and of celebration is taking place. That seems to be the very important point.

- Chögyam Trungpa Rinpoche

Science regularly has to synchronize files across file systems. Normally, this would involve a Ruby script or something heinous in a shell language. But that’s just business. When the synchronization is complex, the problem is much more difficult. Answering questions like these becomes a major painola: was the file deleted from one side, or added to the other? Was the folder renamed or removed?

It’s possible to try to be clever and check all your things into SVN to manage the changes, but with gigabytes of music files, for example, this could be another kind of pain (if I delete “Wham Rap” from my collection - not that I would - I don’t want it kicking around in the SVN repo taking up space).

There’s a better way. Science has found a tool called Super Flexible File Synchronizer. You have to pay for it. I mean you should pay for it because it does a lot and it’s very smart. The Scientific Method over the years has required sync tools - they all make mistakes. Except this one: it hasn’t made one bad guess about what to do yet. And when it’s about to delete a bunch of files, it notices and asks “boy that’s a lot of deletions, are you sure?” Exactly what I would do if someone asked me to delete a bunch of files. “Sure that’s what you told me to do, but geez, that’s an awful lot.”

Open source is great when you can get it - but this tool costs money and the people making it, earn it. If you have to sync files, consider shelling out and making your life a whole lot easier with Super Flexible File Synchronizer. And no one associated with Misuse or Science gains anything by recommending this software.

ActiveMerchant is a very nice little Ruby library that permits connecting to payment processing gateways to charge money against credit cards. To understand how this works, you need to know that there are two separate entities, a “payment gateway” and a “merchant account” (aka a bank). The Payment Gateway receives your request over the Internet for a charge, and authorizes that charge in real-time. The Gateway then hands the authorization/transaction over to the Merchant Account, which converts that credit card transaction into money in your account.

Many Internet credit card companies will act as both Payment Gateway and Merchant Account, but you should be aware that it’s easy to de-couple these, and request that your Payment Gateway process the charge with your preferred Merchant Account. You can save money if you shop around for these services. Authorize.net is one example that seems to be popular with the Ruby/Rails community. Paypal’s Payflow Pro system is an example of a Gateway but not a Merchant Account - you can connect any participating bank to their backend for conversion to cash.

Onto some code. I noticed that many popular examples of ActiveMerchant are out of date, have typo’s or just don’t work. So Science wrote some very simple, put-it-in-a-text-file-and-run-it code that gives a couple of examples on how to process cards with ActiveMerchant and Authorize.net

First, apply for a “test account” with Authorize.net’s developer center. After you’re approved for an account, you’ll get a login_id and a transaction_key. You’ll want to enter those values into the appropriate constants at the top of the code below. Then install ActiveMerchant:

gem install ActiveMerchant -y

That’s it - run the code and you’ll see two successful transactions. Where you go from there is up to you, but hopefully this will help you get off the ground!

require 'active_merchant'

# MOST BASIC EXAMPLE 

# random amount from $10 to $35 - this prevents duplicate transaction errors
charge_amount = rand(1000)+2500 

LOGIN_ID = 'your_login_id_here'
TRANSACTION_KEY = 'your_trans_key_here'
ActiveMerchant::Billing::Base.mode = :test 

#number = '4222222222222' #Authorize.net test card, error-producing
number = '4007000000027' #Authorize.net test card, non-error-producing

credit_card = ActiveMerchant::Billing::CreditCard.new(
:number => number,
:month => 8,
:year => 2009,
:first_name => 'Tobias',
:last_name => 'Luetke',
:type => 'visa'
)

if credit_card.valid?
gateway = ActiveMerchant::Billing::AuthorizeNetGateway.new(
 :login  => LOGIN_ID,
 :password => TRANSACTION_KEY
)
response = gateway.purchase(charge_amount, credit_card)

if response.success?
 puts "success!"
else
 raise StandardError.new( response.message )
end
end

# EXAMPLE USING BILLING ADDRESS

# random amount from $10 to $35 - this prevents duplicate transaction errors
charge_amount = rand(1000)+2500
number = '4222222222222' #Authorize.net test card, error-producing
#number = '4007000000027' #Authorize.net test card, non-error-producing
billing_address = { :name => 'Mark McBride', :address1 => '1 Show Me The Money Lane',
:city => 'San Francisco', :state => 'CA',
:country => 'US', :zip => '23456', :phone => '(555)555-5555' }

creditcard = ActiveMerchant::Billing::CreditCard.new(
 :number => number,
 :month => 3,        #for test cards, use any date in the future
 :year => 2010,
 :first_name => 'Mark',
 :last_name => 'McBride',
 :type => 'visa'       #note that MasterCard is 'master'
)

if creditcard.valid?
  gateway = ActiveMerchant::Billing::AuthorizeNetGateway.new(
   :login  => LOGIN_ID,
   :password => TRANSACTION_KEY)

  options = {:address => {}, :billing_address => billing_address}

  response = gateway.authorize(charge_amount, creditcard, options)

  if response.success?
    gateway.capture(charge_amount, response.authorization)
    puts "Success: " + response.message.to_s
  else
    puts "Fail: " + response.message.to_s
  end
else
  puts "Credit card not valid: " + creditcard.validate.to_s
end