Development mode locally is unexplainable slow

Hi guys,

Recently, my Rails project became oddly slow when running in development mode locally. Example:

Processing SessionsController#new (for at 2011-01-24 19:54:41) [GET] Completed in 320ms (View: 27, DB: 6) | 200 OK [http://localhost/login\]

320ms is pretty slow, but the issue is, that somewhere on top of this, there is a 500ms overhead on doing... *stuff*. Check this:

time curl http://localhost:3000/login > /dev/null

real 0m0.831s user 0m0.005s sys 0m0.008s

I'm running NewRelic as well, but any statistics in there only accounts for the first 320ms.

How do I find out what is eating up the additional 500ms? It's driving me absolutely nuts, because it didn't always do this. I'm wondering if it's the amount of gems we use (currently around 30 or so).

I'm running - ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - Rails 2.3.5

Thanks in advance for any help or hints.

Cheers, Christian

in development 320 ms is not slow, because rails reload your class - structure. What a problem?

That's right, but what happens between 320ms and 831ms?

That's right, but what happens between 320ms and 831ms?

Well, for one thing, the shell loads and executes curl for you.


OK, 20ms accounted for. :slight_smile:

I suspect rails reloads all my gems or something like that, as fs_usage shows a bunch of activity on those files. Is there any way to make rails cache everything between page requests but the actual code?

- Christian

I’m not sure how tied you are to rails 2.3.5 and ruby 1.8, but possibly use this as an opportunity to upgrade to the current standard tech? Ruby 1.9.2 is pretty much rock solid, and rails 3.0.3 is running very very well now.

As for local development time, what kind of system are you running this on, and has it always been this slow? I’m disappointed to see more than 100ms response times on my local dev environment, even running WEBrick (because I tend to be too lazy to change “rails s”) and I’m only on a poor Athlon X2 QL-65 on my laptop, which is little better than a Celeron.