Hi all,
I’m seeing something a bit odd in our rails app. In the application log
file I see the homepage is constantly generated in under 350ms,
sometimes going as far down as 150ms. However, when I run firebug
locally or Pingdom to test how long it takes to load our site, it
constantly shows a much larger “waiting for response” time, usually
around 600-700ms. I was wondering if anyone can help me figure out the
large difference? Where are those 300-400ms spent?
Is it possibly related to nginx configuration?
The server is an 8cpu, 8gb ubuntu installation with a server load of
about 1.6.
Thanks!
firebug is affected by firefox’s speed, the client machine’s speed and
the speed of your network. on a page I just tested on my site, firebug
says 10-100ms per request just in “waiting for response” while ab
(Apache Bench) says it takes at most 19ms total (not just waiting for
response) per request under load (i.e., when doing 4000 requests with a
concurrency of 40). curl says it takes 3-10ms total (not just waiting
for response). I’m running ab and curl on the same machine with Firefox.
remove components until you find the slow piece. what does ab or curl
(using -w and time_pretransfer) say? how fast is it if you run ab or
curl on the nginx server itself rather than across the network? what
does firebug or curl say about a known fast site like www.google.com? I
get about 100ms in Firebug’s “waiting for response” against google.com
but curl ranges from 3-45ms.
and how big (in bytes) is your home page? does it change significantly
for smaller pages?
Firebug is very erratic too, if I hit refresh several times it can
increase by a factor of 10. I wouldn’t put too much weight on what
Firebug says. I don’t know anything about Pingdom.
Hi Troy,
Thanks for your response. It does change when running ab, giving a
smaller total time for the page load, but I’m not sure if and how I can
break ab’s total request time further. Is there a way to make is show
the different phases of the page loading (waiting for response,
downloading etc.)?
Also, on the same machine running Firebug I get much lower “waiting for
response” values for other competing sites as well as general purpose
sites. Most range in the 50-150 ms range while ours is somewhere in the
500-900ms range.
My question is what parameters in nginx can affect the amount of time a
request is waiting for response? How can I try and locate the bottleneck
here? How can I tell if the amount of worker process I have up is
sufficient?
Thanks for helping out again 
Posted at Nginx Forum:
I don’t think ab can do that. Try curl with -w and the time_pretransfer
option.
You seem to have concluded that Nginx is the problem. Are you sure? I
wouldn’t be, I’ve found Nginx to be extremely fast and efficient – I
can complete entire requests in single-digit ms numbers. Have you
removed the network between you and the server from the equation, i.e.,
have you tested it on the same machine as Nginx with curl or ab?
You can locate the bottleneck by reducing it to the simplest case (which
presumably won’t exhibit the problem) and moving out from there, testing
every component and changing one thing at a time until you see the
problem. Then you’ve found the bottleneck. Note that the OS can be tuned
too.
I’m never shocked at how pedantic many technical people are. 
On Sun, Jan 3, 2010 at 12:33 PM, Troy H. [email protected]
wrote:
You can locate the bottleneck by reducing it to the simplest case (which
presumably won’t exhibit the problem) and moving out from there, testing
every component and changing one thing at a time until you see the problem.
Then you’ve found the bottleneck. Note that the OS can be tuned too.
Changing things “one at a time” is often the slowest way to do it… a
binary search is far faster, especially if the number of layers or
components involved is large.
Asuming you have 8 configuration or code changes to try, give them all
an identity number, test a group of 1#-#4, then #3-#4, then just #3 in
isolation.
I’m shocked how many technical people forget good old binary search
when not writing code…
–
RPM