Rails%203%20In%20Action

Serving requests
the changes, you can deploy them to your server using the simple cap deploy
:migrations command. This will update the code on your application, run bundle
install, and then run any new migrations you may have added.
There’s much more to Capistrano than this, and you can get to know more of it by
reading the Capistrano Handbook 27 or by asking questions on the Capistrano Google
Group at http://groups.google.com/group/capistrano.
To run this application and make it serve requests, you could use rails server like
in development, but there are a couple of problems with this approach. For starters, it
requires you to always be running a terminal session with it running, which is just
hackish. Secondly, this process is only single-threaded, meaning it can only serve a single
request at a time.
There’s got to be a better way!
14.6 Serving requests
Rather than taking this approach, we’re going to show you how to use the Passenger
gem along with the nginx web server to host your application. The benefit of this is
that when a request comes into your server, it’s handled by nginx and an nginx module
provided by the Passenger gem, as shown in figure 14.3.
When the client sends a request to the server on port 80, nginx will receive it.
nginx then looks up what is supposed to be serving that request and sees that Passenger
is configured to do that, and so passes the request to Passenger.
Passenger manages a set of Rails
instances (referred to as a pool) for
you. If Passenger hasn’t received a
request in the last five minutes, Passenger
will start a new instance, 28
passing the request to that instance,
with each instance serving one
request at a time. The more instances
you have, the more (theoretical) 29
requests you can do. If there has been
a request within that timeframe, then
the request is passed to one of the
instances in the pool already
launched by a previous request. 30
web browser
nginx
passenger
instance #1
instance #2
Figure 14.3 Nginx request path
27 https://github.com/leehambley/capistrano-handbook/blob/master/index.markdown.
28 The passenger_pool_idle_time configuration option is responsible for this: http://www.modrails.com/
documentation/Users%20guide%20Nginx.html#PassengerPoolIdleTime.
29 There’s a hardware limit (when you run out of CPU and RAM) that will be reached if too many instances are
started up. Things can get slow then.
30 Passenger will scale up instances depending on the speed of requests coming to the application. The maximum
number of application instances running at any one time by default is six, and can be configured by the
passenger_max_pool_size setting: http://www.modrails.com/documentation/Users%20guide%20Nginx
.html#PassengerMaxPoolSize.
407