Modrails ... Slow first request ...

[Mic Pringle]

Hi,

I have just installed modrails for the first time and have set it up
as per the instructions presented when installing, with my copy of
Warehouse from ActiveReload.

Everything seems to work fine, except that the first request to the
site seems excruciatingly slow ... you can see this yourself by
hitting the site - http://svn.dotmic.com/

Once you get past that first request though, every other page loads as
quickly as I would expect ??

Is this behaviour normal ? If not, does anyone know what might be
wrong and how I might go about sorting it ?

Thanks

-Mic

[Hongli Lai]

This is normal. The Rails application has to be started at some point,
and that point happens to be the first request.

If you don't want this, then you can write a little script which visits
your website. This script is to be run immediately after you've started
Apache. Like this:

wget -O /dev/null http://localhost/ 2>/dev/null

It'll force Apache to start the Rails app.

You may also be interested in the "RailsPoolIdleTime" option, as
described in the users guide.

--
Phusion | The Computer Science Company

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

[Mic Pringle]

Hi,

Thanks for the prompt response.

By first request, I mean each time a new user hits the site, not the
actual first single request apache recieves after it has been
restarted.

Again, you can experience this by hitting my site, then restarting
your browser and going back to my site.

Is this still considered normal behaviour ? And if so, does this mean
that the entire Rails framework is loaded for each new request/session/
user that hits the site ?

Thanks

-Mic

On May 8, 9:29 am, Hongli Lai <hon...@phusion.nl> wrote:
> Mic Pringle wrote:
> > Hi,
>
> > I have just installed modrails for the first time and have set it up
> > as per the instructions presented when installing, with my copy of
> > Warehouse from ActiveReload.
>
> > Everything seems to work fine, except that the first request to the
> > site seems excruciatingly slow ... you can see this yourself by

> > hitting the site -http://svn.dotmic.com/

>
> > Once you get past that first request though, every other page loads as
> > quickly as I would expect ??
>
> > Is this behaviour normal ? If not, does anyone know what might be
> > wrong and how I might go about sorting it ?
>
> This is normal. The Rails application has to be started at some point,
> and that point happens to be the first request.
>
> If you don't want this, then you can write a little script which visits
> your website. This script is to be run immediately after you've started
> Apache. Like this:
>

> wget -O /dev/nullhttp://localhost/2>/dev/null

>
> It'll force Apache to start the Rails app.
>
> You may also be interested in the "RailsPoolIdleTime" option, as
> described in the users guide.
>
> --
> Phusion | The Computer Science Company
>
> Web:http://www.phusion.nl/

> E-mail: i...@phusion.nl

[Hongli Lai]

Mic Pringle wrote:
> Hi,
>
> Thanks for the prompt response.
>
> By first request, I mean each time a new user hits the site, not the
> actual first single request apache recieves after it has been
> restarted.
>
> Again, you can experience this by hitting my site, then restarting
> your browser and going back to my site.
>
> Is this still considered normal behaviour ?

That's normal. But as I've said, you're probably interested in the
"RailsPoolIdleTime" option, as described in the users guide. By
increasing it to an insane number (99999999 or something) the Rails
processes will be kept alive forever.

> And if so, does this mean
> that the entire Rails framework is loaded for each new request/session/
> user that hits the site ?

No. The behavior is actually a little more complex than that because
there's a lot of caching involved in order to decrease startup time.

--
Phusion | The Computer Science Company

Web: http://www.phusion.nl/
E-mail: in...@phusion.nl

[Mic Pringle]

Hi,

Again, thanks for the prompt response.

I think I understand now what's happening, but correct me if I'm
wrong.

I had a look at RailsPoolIdleTime, and it defaults to 120 seconds ...
which if I've interpreted correctly means that after 2 mintues of idle
time the Rails application will be shut down. And because I'm
currently the only one accessing my site, and at far greater intervals
than 2 minutes, modrails has already shut down my app, meaning each
time I've visited it's had to reload it ?

I'm also assuming that this may only happen once or twice on a high
traffic site with constant visitors, but as mine isn't that's why
you've suggested maxing out the RailsPoolIdleTime ?

Thanks

-Mic

> E-mail: i...@phusion.nl

[Hongli Lai]

Mic Pringle wrote:
> Hi,
>
> Again, thanks for the prompt response.
>
> I think I understand now what's happening, but correct me if I'm
> wrong.
>
> I had a look at RailsPoolIdleTime, and it defaults to 120 seconds ...
> which if I've interpreted correctly means that after 2 mintues of idle
> time the Rails application will be shut down. And because I'm
> currently the only one accessing my site, and at far greater intervals
> than 2 minutes, modrails has already shut down my app, meaning each
> time I've visited it's had to reload it ?
>
> I'm also assuming that this may only happen once or twice on a high
> traffic site with constant visitors, but as mine isn't that's why
> you've suggested maxing out the RailsPoolIdleTime ?
>
> Thanks

Yes and yes.

--
Phusion | The Computer Science Company

Web: http://www.phusion.nl/
E-mail: in...@phusion.nl

[nick]

Passenger is awesome but I've also had the "slow first request"
problem.

Isn't the problem wth the above solution that EVERY process will live
for 999999 (or whatever) s,

What I want is for ONE spare process to always be available.

(i.e. keep one process available when site is idle. When 1 user is on
it, spawn a 2nd process. etc)

Obviously this needs a bit of latency so that processes aren't
constantly being created/desroyed.

Nick

[Ninh Bui]

I maybe missing the point but won't you still suffer from the performance penalty of creating new processes when you for example get 2 or more simultaneous requests if you don't keep the process alive for long enough. Whatever the case may be, one way to keep one process alive in the way you've requested would be to write a script that would visit your site within a given interval N, where N should be less or equal to the RailsMaxIdleTime. This way, at least one process will always be kept alive and you could similarly apply this trick to create more 'minimum' processes if you should desire so.

[Igal Koshevoy]

Ninh Bui wrote:
> one way to keep one process alive in the way you've requested would
> be to write a script that would visit your site within a given
> interval N, where N should be less or equal to the RailsMaxIdleTime.
> This way, at least one process will always be kept alive and you
> could similarly apply this trick to create more 'minimum' processes
> if you should desire so.

I'm getting that "feature" thanks to my monitoring system poking the
sites each minute to ensure that I have one instance alive at all times.
However, it'd be nice if there was a way to specify this in the
configurations on a per-application basis, e.g.,:

<VirtualHost...
# Minimum instances of this app. Defaults to 0 where all instances
can be shut down.
PassengerMinInstances 1

# Maximum instances of this app. Defaults to 0 where limit is equal
to PassengerMaxPoolSize.
PassengerMaxInstances 4

Thanks again for the good work.

-igal

[Mikel Lindsaar]

On Tue, Jul 1, 2008 at 4:45 AM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:
> Ninh Bui wrote:
> <VirtualHost...
> # Minimum instances of this app. Defaults to 0 where all instances
> can be shut down.
> PassengerMinInstances 1
>
> # Maximum instances of this app. Defaults to 0 where limit is equal
> to PassengerMaxPoolSize.
> PassengerMaxInstances 4

+1

And thanks for passenger, it is great.

Mikel

--
http://lindsaar.net/
Rails, RSpec and Life blog....

[Hongli Lai]

On Jun 30, 8:45 pm, Igal Koshevoy <i...@pragmaticraft.com> wrote:
> I'm getting that "feature" thanks to my monitoring system poking the
> sites each minute to ensure that I have one instance alive at all times.
> However, it'd be nice if there was a way to specify this in the
> configurations on a per-application basis, e.g.,:
>
> <VirtualHost...
>     # Minimum instances of this app. Defaults to 0 where all instances
> can be shut down.
>     PassengerMinInstances 1
>
>     # Maximum instances of this app. Defaults to 0 where limit is equal
> toPassengerMaxPoolSize.
>     PassengerMaxInstances 4
>
> Thanks again for the good work.

As of today, the idle timeouts of the application spawner servers and
framework spawner servers are configurable. They're not yet documented
though. By increasing the 'RailsAppSpawnerTimeout' option to a large
value, such as 99999, you can permanently reduce your application
startup time by 90%, except for the first request. This should be a
viable alternative to the hypothetical 'PassengerMinInstances' option.

[tomg]

I'm experience the 'slow first request' problem with Dreamhost and
Passenger. I'm using RadiantCMS - an awesome Rails CMS - but the
first request is really slow - like 15 - 18 seconds. Obviously folks
like me who are using Dreamhost need to configure one of these:

RailsPoolIdleTime
PassengerMinInstances
RailsAppSpawnerTimeout

But can we modify these, if we are using a hosting service? And if so
which one?

-Tom

> startup time by 90%, except for thefirstrequest. This should be a

[tomg]

a work around is to setup a cron task with curl to hit the server once
every 20 minutes are so.

On Jul 21, 3:05 pm, tomg <tomgu...@gmail.com> wrote:
> I'm experience the 'slow first request' problem withDreamhostand
> Passenger.  I'm using RadiantCMS - an awesome Rails CMS - but the
> first request is really slow - like 15 - 18 seconds.  Obviously folks

> like me who are usingDreamhostneed to configure one of these:

> > viable alternative to the hypothetical 'PassengerMinInstances' option.- Hide quoted text -
>
> - Show quoted text -

[johnsbrn]

I don't think the idle timeout is a viable solution. If you had a lot
of requests and spun up 30 instances, they might never spool down (or
at least it would be an extremely long time before they spooled down).
The min instances is the perfect solution. It gives the best of
Mongrel and mod_rails: dynamic pool size with "always on" instances.

[Hongli Lai]

johnsbrn wrote:
> I don't think the idle timeout is a viable solution. If you had a lot
> of requests and spun up 30 instances, they might never spool down (or
> at least it would be an extremely long time before they spooled down).

For each application root, there is only a single instance of the
application spawner server, so there will never be a situation with 30
application spawner server instances. It effectively behaves as a single
"always on" instance, with the added benefit of being able to quickly
spawn many more instances when necessary.

[mpearce]

I'm a little confused about application vs framework spawner. My
understanding from looking at the code is that framework spawner
launches application spawner and that the default timeout for the
framework spawner is much larger than the application spawner.

I've seen the recommendation in the github wishlist:
"wiki.rubyonrails.org has the app spawner idle time set to 0 and the
pool idle time set to 60 seconds, so that instances release memory
quickly but can also spawn up new instances quickly (in less than half
a second) because the app spawner never shuts down.

This is exactly what I want, since this app is the only one on the
server. If I define the RailsAppSpawnerIdleTime 0 do I need to set
the RailsFrameworkSpawnerIdleTime as well? Will the app idle time keep
the framework spawner alive?

After a few:
Invalid command 'RailsAppSpawnerIdleTime', perhaps misspelled or
defined by a module not included in the server configuration
websrvmng: Service /etc/init.d/httpd failed to gracefully restart

I realized that the variable wasn't in the 2.0.3 release. I'm looking
forward to this. Thanks - passenger has solved _so_ many problems!

mp

> For each application root, there is only a single instance of the

> applicationspawnerserver, so there will never be a situation with 30
> applicationspawnerserver instances. It effectively behaves as a single

[Hongli Lai]

mpearce wrote:
> I'm a little confused about application vs framework spawner. My
> understanding from looking at the code is that framework spawner
> launches application spawner and that the default timeout for the
> framework spawner is much larger than the application spawner.
>
> I've seen the recommendation in the github wishlist:
> "wiki.rubyonrails.org has the app spawner idle time set to 0 and the
> pool idle time set to 60 seconds, so that instances release memory
> quickly but can also spawn up new instances quickly (in less than half
> a second) because the app spawner never shuts down.
>
> This is exactly what I want, since this app is the only one on the
> server. If I define the RailsAppSpawnerIdleTime 0 do I need to set
> the RailsFrameworkSpawnerIdleTime as well?

No, they're independent. The default spawn method in the development
version is "smart-lv2", which skips the framework spawner, so setting
the framework spawner timeout wouldn't have effect anyway unless you
explicitly set the spawn method to "smart".

> Will the app idle time keep the framework spawner alive?

No, they're independent.

> After a few:
> Invalid command 'RailsAppSpawnerIdleTime', perhaps misspelled or
> defined by a module not included in the server configuration
> websrvmng: Service /etc/init.d/httpd failed to gracefully restart
>
> I realized that the variable wasn't in the 2.0.3 release. I'm looking
> forward to this. Thanks - passenger has solved _so_ many problems!

It's safe to run the development version. A number of production servers
are running on it.