2

If using in the controller:

def index
  @time_start_in_controller
    ...
end

and at the end of view, use

<%= "took #(Time.now - @time_start_in_controller} seconds" %>

but isn't the time at the view not the true ending of rendering, because it needs to mix with the layout and so forth. What is a more accurate way (just as accurate as possible) to print out the page generation time right on the webpage?

(update: also, the console showing the log as taking 61ms, but the page definitely took 2 to 3 seconds to load, and the network I am using is super fast, at home or at work, at 18mbps or higher with a ping of maybe 30ms)

update: it is a bit strange that if I use the http performance test ab

ab -n 10 http://www.my-web-site.com:8080

it takes 3 seconds total for 10 requests. But if I use Firefox or Chrome to load the page, each page load is about 3 seconds. This is tunneling to my work's computer back to my notebook running Rails 3, but shouldn't make a difference because I run Bash locally for the above statement and use Firefox locally too.

nonopolarity
  • 146,324
  • 131
  • 460
  • 740
  • You can see this in the logfiles right? The duration of the entire request – Michael Koper Mar 24 '11 at 16:08
  • hoping to print it right on the page... please also see update about log saying 61ms but it took 2, 3 seconds – nonopolarity Mar 24 '11 at 16:11
  • As I'm sure you know, page load time is a lot more than the time executing on the server side. When you measure your 2-3 seconds, How do you measure it? What does the inspector in chrome says about the actual time it saw? – Pierre-Luc Simard Mar 24 '11 at 16:33
  • yeah, I found that on Firefox, the page load time is 250ms, but 6 default Rails `.js` and a few `.png` for 3 seconds total -- I thought the `keep-alive` should make it very fast... some info in http://stackoverflow.com/questions/5422550/for-ruby-on-rails-when-using-webrick-does-it-support-keep-alive-and-why-loadin – nonopolarity Mar 24 '11 at 16:45

1 Answers1

1

in a typical production environment, static content (images, css, js) are handled by the web server (eg. apache, nginx etc) not you rails server. so you should check their logs as well. if you are serving static content from your rails server that could be your problem right there.

If your browser time is slow but the time taken in rails (According to the logs) is fast, that can mean many things including but not quite limited to:

  1. network speed is slow
  2. your dns server is slow and browser can't resolve your dns quickly (this happens with for instance if you use godaddy for your dns server they throttle dns lookups)
  3. the requests concurrency exceeds how many threads you have in rails

one way to debug these types of performance issues is to put something in front of the rails server (for example Haproxy) and turn the logging to full. As they will show how many waiting requests there are and how long the actual request/response transferring took along with how long it took your rails thread to process.

Kalendae
  • 2,256
  • 1
  • 21
  • 23
  • as of right now I am looking at development mode. For production, there will be lots of cache and cache-warming, so the pages won't take much time to generate. I wonder why in development mode, we don't use nginx or apache as well... most of our machines are 4GB or some heavy duty ones are 8GB... running even apache is not that big a deal... – nonopolarity Mar 24 '11 at 18:51