Benchmarking (mt) Media Temple’s Grid-Server (gs) for Rails

Posted on June 7, 2007. Filed under: hosting, Payscroll, Rails, Ruby on Rails |

I remembered that when MT’s first launched their Grid server, I was very eager to try out their offering. So I signed up for an account and then did some benchmarking with a simple Rails app that I had wrote. I thought I would repost my findings here over at BloggingRails. One of the main drawback I found back then was that they had only support Mongrel and not the cluster. I’m not sure that is still the case now.


We love Rails, it’s a great framework and Ruby is one of the most “natural” programming language that I have dabble with so far. And signs are showing that Ruby on Rails is now being more accepted as a mainstream platform for deploying web applications. Particularly, this piece of new that I picked that from Techcrunch about Mediatemple’s Grid Server offering released yesterday. Just a short introduction to what (mt)’s grid-server offering is about:

(mt) Media Temple’s Grid-Server (gs) is a completely new hosting platform that eliminated roadblocks and single points of failure by using hundreds of servers working in tandem for your site, applications, and email. The Grid’s on-demand scalability means you’ll always be ready for intense bursts of traffic… all that for $20/mth
Features Include:

  • 100 GBs of premium storage
  • 1 TB of short-path bandwidth
  • Host up to 100 individual sites
  • 64 MB Ruby/Mongrel container

So each (gs) comes with a 64MB Ruby on Rails container that allows you to run one single Mongrel Thread for one Ruby on Rails app. If you are thinking about hosting more than one application , you definitely need to upgrade your RoR container to the 256MB container for $25/mth or the 1024MB container for $70/mth.

So I couldn’t resist and had to try this out so I signed up for a (gs) account and activation was pretty much automated and I got an email providing IP address/server url and login information to start rolling within a hour. Then I moved on setting up a Rails app with the default 64MB container. Setting up Rails is pretty straight forward and you will use an command line interface that (mt) developed internally for that. So to keep the long story short, you enable your container, then you ssh into your account, the usage stuff like setting up gems/rails, etc and then you use ‘mtr’ (the command line interface) to setup the RoR container. You then add your app to your container, and generate htaccess for your app. After that you can start, restart and stop your RoR app through that ‘mtr’ command.

And so they have done a great job in removing all the dirty works and provided an easy to use wrapper. Another great feature of the ‘mtr’ command is the ability to get memory usage information about your RoR container. So here’s what the test app (the current signup page with mysql backend) that I’m running on a 1024MB container looks like:

status: running
status: stopped
free: 1016640
total: 1048576
used: 31936

So as you can see running one Rails app on your container would take you around 32MB memory and you would not want to stress your container by running 2 Rails app on one 64MB container.
And now on the some unpleasant aspects with the RoR container. From the ‘mtr’ command, you can easily remove your rails app, and add another rails app but after trying that, I found out that after removing one Rails app and adding another, the memory usage almost doubled for some reason. So after some experiments, I discovered that for some reason, after removing and adding my Rails app, the memory usage from the removed Rails app stayed in memory and was not freed even after the app was removed. And I have not upgraded my 64MB container at that point, my memory usage only had like less than 6K unused. And running the “Apachebench” instantaneously killed my (gs) and my GPU did not recover from there.

Nothing works beyond that. (I tried stop and stopping the Rail app with the ‘mtr’ command. And still memory usage is still at the level of around 60MB). But the good thing is, there’s a way to recover the “memory leak” by rebooting your RoR container and rebooting the RoR container takes about 10mins or so to have it up and running cleanly.

And now on to the real exciting part. Benchmarking my container with “ApacheBench”. To do the benchmarking, I use the same test that I mentioned in my previous post, Scaling and Benchmarking Rails, and run the same test, ab -n 10000 -c 200 . I have put the ab output at the bottom of the post if you are interested. But here’s a summary of the results. Mediatemple’s (gs) tops the other Rail hosting providers that I’ve tried and was able to handle approximately ~39 requests/sec at currency level of 100 which is pretty good compared to other shared hosting packages that I have tried:

  • Dreamhost – apache/fastfcgi
  • Rails-targeted shared hosting provider – Mongrel

And memory usage was still well below 40MB:

free: 1010788
total: 1048576
used: 37788

So (mt)’s new Grid Server package is indeed a compelling hosting product that looks attractive to Rails developers starting out to get more action with Rails and want more up time than downtime with their Rails app and as well as web developers that has not much experience with deploying Rails and setting up Mongrel easliy. As for pricing, they are competitively priced at $20 with 64MB dedicated memory usage. You can never compare Dreamhost’s price to Mediatemple’s (gs). Dreamhost is oversold on their servers, my previous experience with them were horrible. If you compare Mediatemple’s (gs) to the other Rails-targetted hosting provider, Mediatemple’s offering might be a little pricer than the host provider but Mediatemple’s (gs) gives you that extra margin over the others with performance and as well as the “scalability” that they promised. (which I have idea of how they define scalability as since the “known” method to scale Rails with Mongrel is running Mongrel Cluster and since Mediatemple’s gs only has the ability to run one single Mongrel thread, I really have doubts that it scales as well as promised.) And that brings up the idea of having the digg community test my RoR container and see if it can withstand the infamous “Digg Effect”!


ApacheBench printout

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd,
Copyright 2006 The Apache Software Foundation,
Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Finished 10000 requests

Server Software: Mongrel
Server Hostname:
Server Port: 80
Document Path: /
Document Length: 2732 bytes
Concurrency Level: 100
Time taken for tests: 0.266707 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 30050000 bytes
HTML transferred: 27320000 bytes
Requests per second: 37.49
Transfer rate: 112.67 kb/s received
Connnection Times (ms)
min avg max
Connect: 61 65 3063
Processing: 103 2587 2905
Total: 164 2652 5968

Make a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

One Response to “Benchmarking (mt) Media Temple’s Grid-Server (gs) for Rails”

RSS Feed for Blogging Rails Comments RSS Feed

Very interesting piece. If you’re looking for a great
a great web host, try Server Intellect. They
are very knowledgeable and our developers
really like working with them.

Where's The Comment Form?

Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: