Rails Deployment | 319Asset hosts for static files
There is yet another way to serve static files. Rather than intercepting requests for
static files at the proxy, you can define anasset host, or another server from which
static files will be served. The Railsimage_pathand similar helper methods will then
use that host to reference files in the public directory. Configuration is simple:
config.action_controller.asset_host = "http://assets.example.com"But this can be inefficient: browsers limit the number of concurrent connections to
one host, so the download speed can actually be limited by the connection rate,
which is often governed by the user’s upload speed.*This can be solved by increas-
ing the number of DNS names from which assets are served, as the restrictions oper-
ate based on names, not IP addresses. In Rails 2.0, the configuration looks like this:
config.action_controller.asset_host = "http://assets-%d.example.com"This will distribute asset requests acrossassets-0.example.com,assets-1.example.com,
assets-2.example.com, andassets-3.example.com. Just point all of those DNS names
at your asset server, and you gain the benefit of increased concurrency without
changing any client settings.
Application Server
With the other pieces in place, we now need the biggest piece of the puzzle: the
application server that handles all of the dynamic requests. Right now, the best solu-
tion is Mongrel.†
Prior to Mongrel, Rails applications were best served using the CGI protocol or some
variation thereof (FastCGI or SCGI). The basic idea behind this is that the front end
web server would talk to the application server using a special protocol, with one
connection per request (see Figure 10-8). CGI has the limitation that one new pro-
cess is created for each request, which is extremely slow for interpreted languages
such as Ruby. Therefore, the FastCGI and SCGI protocols were created. They have
the advantage that they can work with persistent interpreters—one interpreter can
serve many requests over the lifetime of the process. This solution can be scaled by
adding more workers.
However, the front end server is still a limiting factor here. The front end server han-
dles every request from start to finish, something we can actually eliminate with a
load-balanced setup. In addition, using two different protocols confuses things: the
application servers speak FastCGI, and the web servers speak HTTP. To top it off,
Apache’s mod_fastcgi has had a reputation for crashing after being up for a while.
- Seehttp://www.die.net/musings/page_load_time/ for a full explanation.
†http://mongrel.rubyforge.org/