Min pool size suggestion.

[Toby]

My use case for Rails is a collection Radiant sites that are accessed
quite infrequently.

Passenger is brilliant for deployment, but in my case leads to long
initial load times. As the sites are used infrequently, the average
user has to wait for a spawn before seeing anything.

I suggest that the process killing algorithm could have a minimum as
well as maximum pool size. Processes would only be killed if they
exceed their idle time _and_ there are more running processes than the
configured minimum.

That way, hosts like mine could be tuned to provide a reasonable
chance of users finding a running process when they visit, even if the
site hasn't been used for a long time.

[bensie]

I second this idea, as it definitely makes sense to always have at
least one process ready to go at all times. In a shared hosting
environment I can see this would be a waste of resources, but it would
be nice to have the option to set this minimum on dedicated hosts.

[Ryan Bigg (Radar)]

I third this idea.

--
Appreciated my help?
Recommend me on Working With Rails
http://workingwithrails.com/person/11030-ryan-bigg

[Hongli Lai]

We're actually planning on making the ApplicationSpawner server
timeout configurable. The ApplicationSpawner server can reduce startup
time by 90%, plus it only uses as much memory as a single application
instance. So that should solve your problem as well, and would be a
lot easier to implement.

Currently the timeout is defined in a constant,
APP_SPAWNER_MAX_IDLE_TIME, in lib/passenger/framework_spawner.rb.
Could you try increasing this timeout (to, say, 999999; don't forget
to restart Apache) and check whether this solves your problem
adequately?

Regards,
Hongli Lai
--
Phusion | The Computer Science Company

Web: http://www.phusion.nl/
E-mail: in...@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

[Tom Copeland]

On Wed, 2008-05-21 at 20:15 -0700, Toby wrote:
> I suggest that the process killing algorithm could have a minimum as
> well as maximum pool size. Processes would only be killed if they
> exceed their idle time _and_ there are more running processes than the
> configured minimum.

I think someone else suggested something along the same lines - but to
make the min pool size configurable on a per virtual host basis. That
way you could always have at least one process for _each_ vhost waiting
for a request.

Of course, it's easy for us to suggest this and a little bit harder to
actually implement it :-)

Yours,

Tom

[Toby]

> Currently the timeout is defined in a constant,
> APP_SPAWNER_MAX_IDLE_TIME, in lib/passenger/framework_spawner.rb.
> Could you try increasing this timeout (to, say, 999999; don't forget
> to restart Apache) and check whether this solves your problem
> adequately?

Thanks. I've implemented this suggestion and everyone is now really
happy with the performance. On our host the Application Spawn Servers
take about 2.5 seconds to start up, which was the performance hit that
my team was worried about. With a persistent App Spawn Server, things
are very fast. Nice!

Of course, this means that we have a chunk of RAM being used full-time
for each application. We're using standard Ruby. Would RubyEE have a
big effect on the total amount of RAM used by Application Spawn
Servers?

Thanks again,
Toby.