Take the 2-minute tour ×

I am working with a Rails 3RC app and using Phusion Passenger for the first time. It takes about 30 seconds to start up the app on the first request and here is the typical memory consumption for each ruby process in my app:

PID     VMSize     Private   Name
18161 263.5 MB 75.4 MB Rack: /rails_apps/my_app/current

Is that typical memory consumption? My app is about 11MB ( < 4MB if you dont include my /public assets).

It runs fine after the first request if there is one user, but I run into problems when I run some of my custom stress testing scripts, and also when I use my search suggestion feature which makes a bunch of quick ajax calls(which I expected, because the next request comes thru before the first one finishes). Here is what I find odd.. the server starts spawning Ruby threads which take an additional 30 seconds to load, but no other requests can go thru while the spawning is taking place. Just to double check, I tested with browsers on other networks while the processes were spawning just to make sure it was not something specific to my local machine (like all requests being served from one process). These browser requests had to wait until all the new spawns were complete.

So my question is.. is this the typical behaviour of Passenger? Waiting on spawning before any other request can come thru? From looking at the documentation I would think that the other request would be handled by idle ruby processes while the spawning was happening. Here are the versions I am using in case you guys are aware of any incompatabilities. Thanks in advance! I really don't want to go back to Mongrel ;-)

my setup
Quarter slice Rackspace Cloud (4GB RAM & 1/4 of dual quad core)
CentOS 5.4
Rails 3.0RC
ruby 1.9.2dev (2010-05-31 revision 28117) [x86_64-linux]
Passenger 2.2.15 with mongrel

nginx config options:
passenger_max_pool_size 30;
passenger_enabled on; #in / location block..

I tried conservative spawning and I am seeing the same behavior.

share|improve this question
I guess this is the expected behavior of Passenger. According to the Passenger blog: "Previously, when application processes are being spawned, Phusion Passenger is unable to handle HTTP requests until the processes are done spawning, because Phusion Passenger is holding the lock on the application pool while this is happening." I find it hard to believe that Passenger could be used on an app that has a high traffic. It could take 5 minutes for an app to respond after a restart. Aside from that Passenger looks good.. looking forward to v3. guess I have to stick w/ mongrel for now. –  cowboycoded Aug 14 '10 at 2:07
add comment

1 Answer

up vote 2 down vote accepted

Passenger 3 is out with asynchronous spawning. You can even set a minimum number of processes to keep around.

Even with the old behavior, most high-traffic sites don't experience this problem because:

  1. Spawning the first process is usually much faster. For me, Rails apps typically take 5 seconds to spawn.
  2. The smart spawning method makes spawning additional processes much faster, typically requiring only 10% of the original time.
  3. People with high-traffic websites typically set their pool idle times to higher values so that processes don't get shut down during the day and only clean themselves up during the night.

Your memory usage is a bit high. Most Rails apps I've seen require 20-50 MB of private memory.

share|improve this answer
Hongli, thanks for the resonse and thanks for the work you guys have done on Passenger! Passenger 3 looks amazing.. especially the new spawning and zero-downtime restarts. With these new features, the problems I described in my question are not an issue. As for the memory consumption and the process startup time, after using mongrel and thin for the same application, I believe this to be a problem with Rails 3 apps that have many dependencies. Looks like alot of overhead was added to Rails 3 startup time (Bundler, etc..) –  cowboycoded Sep 19 '10 at 14:45
add comment

Your Answer


