casperfabricius.com

Geoffry Grosenbach is cool. And I’ve struggled with the same issues as he has, albeit I’ve been able to build on his work in my own deployment setup. So of course I had to attend his talk on deploying to shared hosts, although most of what he said wasn’t new to me. Geoff’s entertaining and well-designed presentation focused on three areas: How to design a site to run a shared host, how to maintain the site, and how to troubleshoot problems.

Design
First of all, Geoff suggested that only really small sites should be deployed to a shared host. By small, it is not as much disk space, as how much memory and how many CPU cycles the site requires running smoothly. You are restricted on all these three factors on most shared hosts, but you also have the benefit of running on multiple servers – usually the database server will quite powerful, you will have a separate mail server, etc.

Another important thing in designing the application is caching. Geoff explained, that by using the caches_page macro, an html file will automatically be created upon the first hit, and after that; the web server will simply serve that static page without even invoking Ruby, Rails, FastCGI or anything else. The html file is stored in a directory structure that corresponds to the mapping of the action, so if you have for instance the action /da-DK/blogs/show/1, it will store that particular blog for that particular language. So that sounds like quite a big possibility to improve on speed. In order to expire the cached pages, a cache_sweeper needs to be implemented.

Maintaince
Geoff underlined that you need to make sure you don’t have too many zombie FastCGI processes running on your shared host, since you are restricted on number of processes. Maybe Mongrel will be the holy grail giving a nice, reliable way to run sites on a shared host, Geoff said, and this was somewhat confirmed by the “Deploying Rails” presentation by Ezra Zygmuntowicz the following day, stating that the future of Rails deployment definately belongs to Mongrel.

For monitoring our Rails applications, Geoff suggested Montastic.com or dwatch, which he has written a great tutorial on using.

Troubleshooting
Finally, Geoff gave some advice on how to debug and fix your problems when your site is not working on the server. The hash-bang (or is it she-bang?) lines has to actually point to place Ruby exists on the server, and it is a good idea to set export RAILS_ENV="production" in the ~/.bashrc or ~/.bash_profile to indicate that this the production site, instead of hardcoding it in environment.rb or relying on the shared host to set it.

./script/about, ./script/server –e production and ./script/console production are all good indicators of whether or not the actual site are running on the shared host, but also, the various logs produced can be good indicators of where the problem is, especially apache_log, production.log and fast_cgi.log.

Conclusion
Deploying Rails can be frustrating, and deploying it to a shared host with no control and lots restrictions can be a nightmare, so, as Geoff started out by saying, his talk was not a tutorial or a lesson, it was therapy.

But really the morale here is: Don’t use shared hosts for Rails, and if you do, make sure it’s only very small applications, or only for test purposes. As Ezra said at his talk on deployment: “Rails is a pig”. Once you want people to actually use your site, you should go with a Virtual Private Server (VPS) – or of course a dedicated setup if you can afford it – since you will get a certain amount of memory guaranteed, and you will have less users pr. machine. Ezra adds that you always go for a VPS host that uses XEN, since this platform uses almost no resources on its own.