0

I'm reading this article:

http://www.modrails.com/documentation/Architectural%20overview.html#web_app_models

It talks about how Phusion Passenger extends Apache2 to act as an application server. When an HTTP request comes in, the Phusion Passenger module checks whether the request should be handled by a Phusion Passenger-served application. If so, then the module spawns a process for the application, if necessary. Forwards the request to the application process, and forwards the response back to the client. In order to enhance the spawning process, passenger acts as a spawn server which caches Ruby on Rails framework code and application code in memory.

This way every time a new request comes in, when a process is spawned it references the cached code and spawns the process quickly. But despite caching spawning is still expensive compared to an http request. So an application pool is used. I don't understand what an application pool is. This is what it says:

Spawned application instances are kept alive, and their handles are stored into this pool, allowing each application instance to be reused later. Thus, Passenger has very good average case performance.

What does it mean "kept alive" and their "handles are stored in this pool". I thought that's the point of caching - to keep data alive for later. So I don't see how this is different.

3

There isn't a binary on/off situation going on here. It's a continuum.

One extreme of the continuum is the old CGI model of web programming: the web server starts an application afresh to service each request that comes in. The application dies when it finishes handling the request. Because the application has to start afresh each time, it has to rebuild the application state on each request. This is expensive in both time and data space.

And so, over time, many options have been created to reduce the expense:

  • FastCGI uses the CGI model, but it keeps the CGI program alive after starting it the first time, and just keeps feeding new requests to it. This not only avoids the expense of re-launching the CGI program, it lets the app keep state in RAM.

  • mod_{perl,php,ruby,...} brings the actual application interpreter into the web server instance, and these systems tend to do the same sorts of things that FastCGI does: after loading and compiling each script to some kind of bytecode, it just feeds new requests to it without re-doing all that work.

  • This system you're talking about is just one level higher than the mod_foo scheme, where it keeps a logical model of an entire application in RAM, so that even fewer things have to be re-created on each request. Exactly how this differs from the base behavior you get with mod_foo I couldn't say. The point, though, is that it is not a difference in quality, just of amount.

  • The next step down the line, which may help you to understand where this Phusion Passenger is trying to go, is to keep everything running within a single long-running application instance. This is how web servers based on Erlang work, such as Nitrogen. Visit that second link for a comparison with the way Apache-based applications work.

    I believe many Java based application servers work the same way.

Bottom line, all of this is an optimization game, trading RAM and runtime complexity for speed.

2

The terms "kept alive" and their "handles are stored in this pool" is in reference to something different than caching.

Caching

Caching is a mechanism where data that's expensive to acquire is kept in a fast accessing location for reuse later on. You'll see it used in a variety of places such as:

  • looking something up in a database
  • resolving a server's IP address
  • accessing a file from a hard drive

Pooling

The "kept alive" they're referring to in the Phusion Passenger documentatoin is referring to forcing an application to stay up indefinitely so that we can save on the time it takes to launch the application.

When servicing a web request you want the application to be as responsive as possible. If it takes several seconds for an application to start up, then several seconds more to request data from a database, there's no way that you'll be able to create a responsive web application.

So instead what's done is a light frontend is constructed that will accept connections and then keep multiple instances of the application up and running at all times, and then the frontend will do the following:

  1. assign an incoming connection to one of the already running instances of app
  2. take the results from this running instance
  3. pass the results back to the client
  4. put the running instance of app back into a "ready to process" state

Example

I like to use the example of having multiple registers at a grocery store. Each lane is an instance of the app server, and each can only process a single user at a time, but together they can service several.

If you take a look at Ruby's Mongrel HTTP server it was designed so that it could be run in a pool in much the same way.

One popular configuration was to run Apache HTTP Server 2.2 as a load balancer using mod_proxy_balancer in conjunction with several Mongrel instances. Each Mongrel instance would run on a separate TCP port, configured via the mongrel_cluster management utility. Until recently, Twitter was a notable instance of this configuration.

Mongrel was capable of serving Ruby on Rails powered sites without requiring any other web servers, though as a single-threaded application this configuration is unsuitable for all but light loads

3
  • This is a good answer. I just have a question. You said "a light front-end keeps multiple instances of the application up and running at all times". Do you happen to know how many instances it keeps running? Is that dependent on how much RAM the computer has? Jul 24 '13 at 16:28
  • @JohnMerlino - that's typically configurable. It usually depends on a number of factors, RAM being one of them. CPUs, and database resources along with others.
    – slm
    Jul 24 '13 at 16:30
  • @JohnMerlino - again Mongrel has been replaced with Thin but you can refer to the Pragmatic Developers book which discusses running Mongrel in a cluster: media.pragprog.com/titles/fr_deploy/chap6.pdf
    – slm
    Jul 24 '13 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.