0

I´m having problems doing apache benchmarks with ab on my servers. Basically, all the results got a high standard deviation, invalidating the results.

This is an example resultset:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    25   33  81.0     27    1805
Waiting:       24   32  80.2     25    1785
Total:         25   33  81.0     27    1805

Percentage of the requests served within a certain time (ms)
  50%     27
  66%     28
  75%     29
  80%     30
  90%     36
  95%     47
  98%     81
  99%    105
 100%   1805 (longest request)

I have tried remotely/localhost with the same results. Any idea of what can be the problem?

Thanks in advance.

  • 1
    What kind of workload is this? Does it depend on locking, or perhaps on an external system like a database or dns? – Joris Sep 19 '10 at 19:22
  • It´s a benchmark above a php/mysql dynamic site. –  Sep 19 '10 at 22:33
  • How many concurrent requests do you run from ab? 1 % of your requests is taking much more time. Could be locking in your php app. Try to profile your application and see where the bottleneck is. – Wouter de Bie Sep 20 '10 at 06:37
  • I´ve tried with 1,10,100 concurrent connections, all with similar results... –  Sep 20 '10 at 11:38
  • What mysql storage engine are you using? Could it be that a very large table is locked (in a MyISAM setup) by something and requests queue up because they are waiting for database access? – Wouter de Bie Sep 21 '10 at 06:20

1 Answers1

0

A few general things you can try:

  1. Isolate the Server -- Don't expect accurate benchmarks on a server that is processing other requests. Ideally you want it only running the requests from ab. The best time is right after rebooting the server although see the next item below....
  2. Cache Warm Up Time -- After a server reboot warm up the various caches by running the benchmark once (or a few times) and ignore the results, that is unless you want to include the effect of a cold cache in the results. Depending on the exact application this "warm up" could be as little as loading the page once or may require more a complex procedure.
  3. Slow Query Log -- If using MySQL you can enable the slow query log to see if there is an obvious query, or several queries, that are responsible for the slow page loads.
  4. Narrow Down the Cause -- If the random slow page loads still persist your best bet is to narrow down their source. The exact method depends on the complexity of your application but it could involve creating a bare-bones test application, temporarily commenting out code, or playing with configuration settings.
uesp
  • 3,384
  • 1
  • 17
  • 16