Buy Enough Resources for Production
A large number of Ruby applications run in the cloud today. There are many providers of deployment infrastructure, but the better ones tend to be expensive. So you often have to find the optimal compromise between the price you pay and the resource limits you get for that price.
Hosting providers usually emphasize the number of CPU cores and the size of the storage in their pricing plans. Both these numbers are irrelevant. CPU performance is usually not a problem, and storage can be easily added. Here are what I believe are the most important criteria when evaluating the potential deployment stack:
-
Total RAM available.
After reading this book, it should be no surprise that memory comes first in my list.
-
I/O performance.
This is the most overlooked parameter, which is often hard to evaluate without deploying at least the test application. It doesn’t matter for some applications, but if you write logs or cache to disk, pay attention to it.
-
Database configuration.
If you do not set up the database server yourself, make sure your provider follows the best practices that we talked about earlier.
-
Everything else.
Don’t be afraid to pay for more memory. That is often cheaper than paying for extra servers (virtual machines). For example, as of this writing, Heroku, one of the most popular Rails deployment solutions, offers two kinds of dynos (virtual machines): 1X and 2X. The first has 512 MB of RAM, and the second has 1024 MB. 2X is about 2--2.5 times more expensive.
On the 1X dyno you can run only one Rails instance because their average size is about 250--300 MB. On the 2X dyno you can run three instances—for example, three Unicorn workers. That more than justifies the increase in cost.
Also, when your Rails application goes bad and grows in memory, you’ll at least have some extra memory on a 2X dyno to be used before you cycle the offending process. In my experience that makes all the difference. With a 1X dyno your application can just stop responding whereas 2X will slow down for a short time.
I/O bit me several times in the past. At Acunote, we used to deploy on Engine Yard before we bought our own hardware. Their virtual machines at the time did not have their own storage, and instead used the network filesystem (RedHat GFS).
GFS seemed to work really well for us until I found that certain cache expiration calls took too long to execute.
We cached to disk, and expired it by traversing the whole cache directory and matching the file paths to the expiration regular expression. It turned out that GFS had a slow fstat() implementation, so traversing the large cache directory could take several seconds. So we had to change our caching strategy to limit the number of directories in the search path for expiration.