Phusion Passenger spawning problems

Question

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.

Answer 1

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.