问题
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
回答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
回答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.
回答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.
回答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.
回答5:
Maybe you need to adjust the PassengerPoolIdleTime var in apache conf. Set it to 0 to never stop your rails process.
来源：https://stackoverflow.com/questions/909225/first-request-to-rails-app-is-very-slow