So here’s my problem. I’ve written an RoR application and I’ve managed to get a server up and running with Apache and Passenger. Im paying quite a bit for my server, but I have no idea if my application is effectively using the server’s resources. How do I gather metrics to make sure that I can configure my web server(Apache) and application server (Passenger) optimally to serve my application?

I realized that there are 3 parts in the answer to this question. First, we need to understand how Apache and Passenger are designed to handle incoming HTTP requests together. Second, we need to understand what the various directives available for Apache and Passenger mean. And finally, we need to see how we can gather metrics and tweak these directives to the optimal setting.

Im going to address each of these 3 parts in 3 blog posts. So lets get started with the first, how Apache and Passenger are setup to work together.

There is an explanation in the Passenger docs on Passenger’s Architecture but frankly, I could not digest it in one read. So I’m going to summarize it for our purposes here.

passenger architecture mindmap

mod_passenger sits in the control process and every child process of Apache's

Apache has an architecture wherein modules can be plugged in to add functionality to it. Passenger provides the mod_passenger module which allows Apache to act as an application server. The above diagram (taken from the Passenger docs) represents Passenger’s architecture when the default prefork MPM is used with Apache.

The mod_passenger module sits in the main control process and every worker process that Apache generates. It also maintains 2 other things – a spawn server and an application pool.

The Passenger Spawn Server further, has 3 components – Spawn Manager, Framework Spawner and Application Spawner. Now according to the Passenger documentation,

“A particularly interesting thing to note, is that a lot of the memory occupied by Ruby on Rails applications is spent on storing the program code (i.e. the abstract syntax tree (AST)) in memory. This is observed through the use of the memory statistics function in Ruby Enterprise Edition. Also, a lot of the startup time of a Ruby on Rails application is spent on bootstrapping the Rails framework.”

This means that performance can be increased considerably if the Rails Framework code and your application code can be cached and reused. This is primarily what the Framework Spawner and Application Spawner do. The Framework Spawner spawns and caches an instance of every Rails version that your applications use. Similarly, the Passenger Application Spawner spawns instances of your application to serve requests. The diagram below (also taken from the Passenger docs) represents this.

spawn server architecture mindmap

Each of the top 2 layers is responsible to handle only its immediate children

The application pool is simply a pool of application instances that can be used to handle incoming requests.

So when an HTTP request comes in to Apache, it passes it on to mod_passenger, which checks out an application process from the pool and marks it as busy. If all app instances in the pool are busy and the pool limit has not been reached yet, then mod_passenger will place a spawn request to the spawn server/manager. The spawn manager will pass on the request to the correct Framework Spawner Server. The Framework Spawner will then forward it to the correct Application Spawner Server which will then spawn a new application instance to serve the request. The lifetime of this application instance is then maintained directly by mod_passenger.

So that, is typically how Apache and Passenger dance together. For a more detailed run through however, I recommend the Passenger Architecture Document. It is definitely an interesting read. A couple of other pages that you might like to refer :

Apache MPM modules –

Ruby Enterprise Edition –

In the next article, we’ll take a look at a few basic directives for Apache and Passenger.

Tags: , , , , ,


  1. well worth the read. I found it very informative as I have been researching a lot lately on practical matters such as you talk about…

Leave a comment