First request to Rails app is very slow

Question

always the first request (of a working session) to my Rails app is lagging. Switching to production mode doesn't help.

I use mongrel and the other requests are handled with acceptable speed.

How do I make it faster?

Regards

Pupil

Answer 1

If you post the contents of the log as that first request is processed then perhaps we can figure out what's making it so slow. For example, this is my log as the first user accesses the site

Booting Mongrel (use 'script/server webrick' to force WEBrick)    
Rails 2.1.0 application starting on http://0.0.0.0:3000    
Debugger enabled    
Call with -d to detach    
Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
/usr/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/mime_type.rb:66: warning: already initialized constant CSV
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.5 available at 0.0.0.0:3000
** Use CTRL-C to stop.


Processing SessionsController#new (for 127.0.0.1 at 2009-05-26 12:26:00) [GET]
  Session ID: de2acf074759026e1ed6205724f547a9
  Parameters: {"action"=>"new", "controller"=>"sessions"}
Rendering sessions/new
Completed in 0.00587 (170 reqs/sec) | Rendering: 0.00298 (50%) | DB: 0.00092 (15%) | 200 OK [http://localhost/]

I think 170 reqs/sec is fine for our app but others may find that slow. You can see from the stats that rails provides that half of the time required is spent rendering the response - in this case generating the HTML for the login screen. If this request was taking a long time, my first port of call would be the views and helpers associated with the login screen.

If you do have a system that takes a long time to initialize itself on the very first request then why not be sneaky and write your own startup program which first runs rails and then sends a fake request in via curl. That way your users never see the problem.

Chris

Uncounted

Thanks for your hint. Here is my logfile: pastie.org/private/ih2mpcmjpofp5jmfsvw Sometimes, it lasts much longer than 1600 ms to answer my request. I really don't have a clue... – Pupil

What version of rails are your using? Completed in 10367ms (View: 1572, DB: 450) | 200 OK [localhost/search?search=stefan+] It looks like it's taking 10 seconds to answer the first request. I guess that searching again for the same query "stefan" is much faster? How long does it take to find a different record? Finally how long does it take to search for a non-existant record? – Uncounted

Answer 2

It can be because you are:

• requiring and loading a number of plugins and gems

• making a connection to an external service (then caching)

• caching your own pages and that only occurs after the first request unless you 'warm' the cache

Any one of these will inevitably increase the response time of the first request.

Ambition

Answer 3

It may be the same reason as our applications taking a long time the first time we kick them off in Websphere.

WAS has to do a lot of initial work to set up the containers when a new version of the application is installed (or WAS is restarted).

The workaround we used was to modify the install scripts and WAS startup scripts so that they automatically browsed to the application (main page and selected other pages) as soon as it was running. That way, the first real access to it was at full speed.

I have no idea how to do this with Ruby or even whether it's possible. You'll have to figure that one out.

Caporetto

It's possible - you can use a simple script to request a page from all the rails apps using curl/wget to achieve the same effect. – Abirritate

Answer 4

I guess you are using Ferret for full-text search? Might it be that the ferret connection takes a while to initialize? When I check your log it seems that both the db and the view take a normal amount of time but the total is still 10 seconds. So I must be something else that's why i'm guessing Ferret might be the problem.

Marduk

Answer 5

Maybe you need to adjust the PassengerPoolIdleTime var in apache conf. Set it to 0 to never stop your rails process.

Doerr