A couple of weeks ago there was a post on the FiveRuns blog about automatically installing the Rails stack on an Ubuntu 8.04 VPS.
I prefer to use Passenger and Ruby Enterprise Edition when running my Rails app, so inspired by the FiveRuns script I wrote my own version – here is the gist on github.
# Inspired by http://blog.fiveruns.com/2008/9/24/rails-automation-at-slicehost
apt-get upgrade -y
apt-get -y install build-essential libssl-dev libreadline5-dev zlib1g-dev
apt-get -y install mysql-server libmysqlclient15-dev mysql-client
apt-get -y install ruby ruby1.8-dev irb ri rdoc libopenssl-ruby1.8
tar xzf $RUBYGEMS.tgz
# Install Ruby Enterprise Edition
tar xvzf ruby-enterprise-1.8.6-20080810.tar.gz
yes '' | ./ruby-enterprise-1.8.6-20080810/installer
# Install Passenger
/usr/bin/gem1.8 install -v=2.0.3 passenger --no-rdoc --no-ri
apt-get -y install apache2-mpm-prefork apache2-prefork-dev
yes '' | passenger-install-apache2-module
# Create sample Rails app
/usr/bin/gem1.8 install rails --no-rdoc --no-ri
rails -d mysql hello
./script/generate controller welcome hello
echo "Hello World" > app/views/welcome/hello.html.erb
rake db:create RAILS_ENV=production
# Create the Apache2 Passenger module files
cat >> /etc/apache2/mods-available/passenger.load <> /etc/apache2/mods-available/passenger.conf <<-EOF
# Create a site file for the sample Rails app
IP_ADDRESS=`ifconfig eth0 | sed -n 's/.*dr:\(.*\) Bc.*/\1/p'`
cat >> /etc/apache2/sites-available/hello <<-EOF
# That's it!
The script assumes that you have ssh access as root to a clean Ubuntu 8.04 install.
The script will install
- Ruby 1.8.6
- RubyGems 1.3.0
- Passenger 2.0.3
- Ruby Enterprise Edition 20080810
- Apache 2.2.8
- MySQL 5.0.51a
- A sample Rails app
Note that the Passenger installer will install the latest Rails (2.1.1) and a bunch of other useful gems.
Assuming that your server IP address is 192.168.185.128 you can run it like this:
ssh firstname.lastname@example.org "wget -O - http://gist.github.com/raw/16225/a6a16b3a38cd3486679b96fa0f3446e58f3b8423 | sed -e s/$'\r'//g > install.sh; /bin/bash install.sh; rm install.sh"
Sit back and enjoy – in less than ten minutes you will have the full Rails stack and a sample Rails app running. Take a look at it on http://192.168.185.128/welcome/hello
Yeah! I am a Rails contributor!
In an application at work we are using a Rails REST application for the backend of the application and another Rails application as the frontend. The frontend application does not use the database at all but only the REST api provided by the backend application.
When sending lots of data between the two applications serializing to and from XML turned out to be a performance bottleneck. We turned to JSON and this improved performance significantly.
The JSON support in ActiveResource was added recently and there are still some areas where XML is better supported than JSON. So I submitted a patch to improve the JSON support. The patch got submitted to trunk in this changeset.
It feels really good to contribute back to Rails when Rails have brought me so many hours of joy
Boy, things have come a long way since I first installed SLS Linux on my pc using floppy discs back in 1994
These days I prefer Ubuntu 6.06 LTS server edition. It is supported until 2011 – nice that you don’t have to reinstall the server in a year or two. Furthermore, deprec makes it extremely simple to setup a Rails stack on an Ubuntu server.
nginx. Nginx is fast, stable, lightweight and has easy configuration.
Usuyally I use the one built in to nginx.
Alternatives: Pen or HAProxy.
Well, Mongrel of course. In a cluster handled by Mongrel cluster.
MySQL. It’s the database used by most Rails applications. Furthermore, it has some nice scaling support with master-slave setups. A couple of years ago I used and liked PostgreSQL a lot. I still prefer PostgreSQL’s query analyzer to MySQL’s.
What if tv2.dk (one of the most popular Danish sites) was running Rails and ran on Amazon EC2? This posting is a followup to this posting
Let’s assume that we on average during 24 hours have 50 requests/sec. The traffic during the 24 hours could for example be distributed like this
|00 – 08
|08 – 11
|11 – 12
|12 – 14
|14 – 15
|15 – 24
This works out to be 50 requests/sec on average. As we saw in the tv2.dk on Rails blog posting each quad core server will get you 80 requests/sec. Unfortunately we have to have servers that have enough power to satisfy the peak number of requests and not the average number of requests. In this example we need four quad core servers in order to be able to serve the 250 requests/sec needed from 12-14 (actually they are able to serve 320 requests/sec). So on average we need one server but in the peak hours we need four servers.
What if we were able to adjust the number of servers dynamically to satisfy the current load on the website?
Amazon EC2 to the rescue! Amazon EC2 is a service that allows you to run one or many virtual servers and you pay by the hour for each virtual server. So we can start and stop a number of virtual machines depending on the load on the website. Each EC2 instance has one (virtual) cpu core so with 10 mongrels doing 2 requests/sec it should be able to handle 20 requests/sec.
So how many servers do we need to run?
||# of servers
|00 – 08
|08 – 11
|11 – 12
|12 – 14
|14 – 15
|15 – 24
If we calculate the number of “server hours” it is 74. How much is this going to cost? Using the AWS Simple Monthly Calculator it turns out to cost 222$ for a 30 day month. Not too bad! Of course we have to add a server for static content (or use Amazon S3) as well as a couple of DB servers. With a small instance server for static content and two large instances (virtual quad cores with 7.5 GB ram) the monthly bill goes up to 811$ – still not too bad.
But you also have to pay for traffic. I will cover that in another blog posting.
Recently I started wondering: What kind of server setup would it take to run one of the most popular sites in Denmark if it was running Rails?
According to FDIM (the association of Danish Internet media) tv2.dk was the thirdmost visited site in Denmark during August 2007:
|Number of users
|Number of visits
|Number of page views
142 million page views! That’s a lot! But how much data is this?
According to Alexa the three most popular subdomains of tv2.dk are galleri.tv2.dk, nyhederne.tv2.dk, and vip.tv2.dk.
Using YSlow we get a picture of the total page size and the number of http requests for the main page of each subdomain:
||Total size 140.1K
||HTTP requests 19
||Total size 580.2K
||HTTP requests 85
||Total size 464.4K
||HTTP requests 58
The average page size is 395K and the average number of requests per page is 54.
The number of page views for August is 142.132.680. This translates to an average of 53 page views/sec. Given the average page size and number of requests this translates to an average bandwith usage of 20.5 MB/sec and an average of 2866 request/sec.
What kind of server setup do you need to handle this amount of traffic?
But what about the Rails part? If we assume that each page view corresponds to one Rails request we have to handle 53 Rails requests/sec. If we assume that the average request time is 500 ms, each Mongrel can handle 2 requests/sec. So we have to have 27 Mongrels to be able to handle 53 queries/sec. As noted in the excellent article Scale rails from one box to three, four and five by Courtenay a rule of thumb is that each cpu core can handle 10 Mongrels. So with a quad core machine we should be able to handle 2*10*4 = 80 Rails requests/sec. Each Mongrel uses in the range of 60-100 MB, so the machine has to have 4*10*80 = 3200 MB ram. Rails applications can be built to scale quite well, so adding additional quad core machines with 4 gigs of ram should get you another 80 requests/sec. With 4 of these machines you should be able to handle 320 requests/sec.
There must some database servers to handle all the data. There a several ways to setup these servers. Take a look at Courtenay’s article for an explanation of these.