There are several different ways to run your Rails app. Starting from simple  $ rails server and to Phusion Passenger, which is quite complex tools itself. Today, though, I want to focus on nginx.

nginx

In case you’re not familiar with this wonderful tool,

Nginx (pronounced “Engine-X”) is an open source Web server and a reverse proxy server for HTTP, SMTP, POP3 and IMAP protocols, with a strong focus on high concurrency, performance and low memory usage.

The main difference between nginx and Apache is that nginx doesn’t spawn a new process or thread for every new connection. It uses a very tight cycle inside a worker process to handle all connections one-by-one. This way it dramatically decreases the memory footprint required, allowing more concurrent connections.

nginx will be used as a frontend web-server for our Rails webapp.

As you probably know, recently I fell in love with Amazon AWS. It’s all nice, but this kind of relationship comes at a price, and the price tag for running even s1.small instance can be quite high. So here I offer the configuration specifically crafted to efficiently run on t1.micro AWS instance, which is (almost) free to have.

I will explain only relevant configuration lines here, but you can find complete nginx.conf and myapp.conf files at the end of this post.

nginx.conf

Core

First of all, we define a number of worker processes. In case of nginx, the recommendation is to make it equal to the number of processor cores available. As I said before, these workers are not the same as Apache’s, so we can use just one of them:

In order to free some CPU cycles, we will adjust a timer resolution. Basically, it means how often nginx calls  gettimeoftheday() function (no default value, nginx documentation provides 100ms as an example):

We want to be able to open as many files as possible within a single nginx worker process without crashing, so we’re increasing this number (default is 1024, you might also want to increase fs.file-max sysctl param):

To get most of it, we increase the number of simultaneous connections and use  epoll type of polling, which is the ideal method for any Linux 2.6+ distribution (default is 1024 for worker_connections):

Use Host header instead of  server_name for redirects:

Don’t tell the world the intimate details of our nginx installation:

Network

Use Linux  sendfile() for better performance:

We want to send all response headers in one packet. This allows a client to start rendering content immediately after the first packet arrives:

Generally, we want Keep-Alive timeout to be no lower than an average time a user spends on a page before requesting a new one. Google Analytics can give a great idea of what this time is for your website:

Send small data chunks immediately – don’t use Nagle’s Algorithm and increase responsiveness:

As we’re aiming at fast clients, we want to decrease default timeout for waiting client data to save some more memory (default is 60s):

Decrease memory requirements for storing request headers (default is 1024 bytes):

Increase largest allowable request body size. Essentially, this is the maximum size of file upload (default is 1m):

Files

For better performance we enable caching of open file descriptors, information about existence of files/directories, etc. Please note this is not content caching (it uses proxy_cache, which is discussed later):

Cache

In order to increase performance and cut memory footprint we enable content caching. Almost all parameters are quite self-explanatory. levels parameter sets the number of subdirectory levels:

nginx cache uses composite keys to store cached content. We want to slightly improve it to have different cache for different request methods (GET / POST):

And we globally enable proxy caching:

By default, only content with HTTP 200 response codes is cached. The webapp I was developing refreshed information once a day, so it was pretty safe to have all pages cached for 24 hours:

Each time a Rails app tries to set a cookie, even if it’s not used. So we can safely ignore it along with some other headers which prevent nginx from caching. But, please, use this config line with caution, as for many cases it would break your apps!

We want to increase timeout to allow caching engine enough time to answer:

We also slightly increase proxy memory buffer for faster responses:

Compression

We enable compression for network bandwidth optimization and faster response times. Here it’s disabled for broken/unsupported browser and support for HTTP/1.0 is added:

Slightly decrease a number and size of memory buffers used to store compressed data:

Slightly increase compression level (1 is default and the lowest, 9 is the highest):

Compress everything no matter the size (default is 20 bytes):

Compress additional Content Types (default is only text/html):

Enable compression for proxies as well, but do not compress everything. Otherwise we risk confusing remote proxies:

myapp.conf

We use unicorn server as a backend for our Rails webapp with a disabled fail_timeout option:

General server settings:

First we try to open static files, and if that fails we go to the @app section:

Here we have a link to the previously defined upstream server and set necessary HTTP headers to give relevant information to our Rails app:

Here we provide paths for the static content. Please note that we don’t want robots.txt and favicon.ico  requests to pollute our access.log:

And, finally, we gracefully handle any 5xx errors our Rails app might run into:

Before and After — Results

So here is how my global-trend-finder.com webapp did before performance optimizations:

Just terrible, isn’t it?

And what we’ve got after:

Nice difference, eh?

gzip compression allowed to decrease response times three-fold. Another two-fold decrease was from open files caching. But, of course, most of the difference came from proxy_cache.

Files

As promised before, here are the full versions of nginx.conf and myapp.conf files.