Analyzing Web Application Speed

I'm a bit confused because the logical/programmer brain in me says that if all things are constant, the speed of a function must be constant.

I am working on a PHP web application with jqGrid as a front end for showing the data. I am testing on my personal computer, so network traffic does not apply. I make an HTTP request to a PHP function, it returns the data, and then jqGrid renders it. What has me befuddled is that sometimes, Firebug reports that this is taking 300-600 milliseconds sometimes, and sometimes, it's taking 3.68 seconds. I can run the request over and over again, with very radically different response times.

The query is the same. The number of users on the system is the same. No network latency. Same code. I'm not running other applications on the computer while testing. I could understand query caching improving performance on subsequent requests, but the speed is just fluctuating wildly with no rhyme or reason.

So, my question is, what else 开发者_如何学Gocan cause such variability in the response time? How can I determine what's doing it? More importantly, is there any way to get things more consistent?

If you use the Apache Benchmarking tool (ab) you can get a set of statistics based on multiple accesses and multiple concurrent accesses, giving you min, mean, median and max access times (and stddev) broken down by connect, processing and waiting; and percentiles... making it an extremely useful tool for identifying if this is really a problem or an aberration.

While it can't diagnose the cause of performance problems, it can tell you if you really do have a problem

The first thing you should do is profile your code (see Simplest way to profile a PHP script). This will show you where your bottleneck is, and then you can figure out why your response times are fluctuating so much.

If you are using Firebug to determine speed you need to consider that both Firefox and PHP are caching resources. PHP, in particular, has a built-in opcode cache to minimize subsequent runtimes. This shows up as a long run on the first instance, followed by a number of short-runs on refresh. I concur with rfw to go deeper in your analysis.