It’s been a pretty busy, and mind numbing work week (and it’s only Tuesday). Anyways, my IT team has been growing fast and we started using Drupal as our collaborative documentation / issue tracking software. Since we’re using some pretty large and hefty modules Drupal has gotten quite slow. Here’s the output from ab, no optimizations:
Concurrency Level: 10
Time taken for tests: 54.490 seconds
Complete requests: 100
Failed requests: 0
Broken pipe errors: 0
Non-2xx responses: 101
Total transferred: 351748 bytes
HTML transferred: 322458 bytes
Requests per second: 1.84 [#/sec] (mean)
Time per request: 5449.00 [ms] (mean)
Time per request: 544.90 [ms] (mean, across all concurrent requests)
Transfer rate: 6.46 [Kbytes/sec] receivedNot exactly stellar performance! However, as you can see from these following we can achieve an 8.5x performance increase in less than 5 minutes of work…
The first thing I did was enable Drupal’s built in caching. This increased the req/second to 5.16, a 2.8x performance increase, 10 seconds of work.
Concurrency Level: 10
Time taken for tests: 19.363 seconds
Complete requests: 100
Failed requests: 0
Broken pipe errors: 0
Non-2xx responses: 102
Total transferred: 363096 bytes
HTML transferred: 323440 bytes
Requests per second: 5.16 [#/sec] (mean)
Time per request: 1936.30 [ms] (mean)
Time per request: 193.63 [ms] (mean, across all concurrent requests)
Transfer rate: 18.75 [Kbytes/sec] receivedWe can do better than that. Here are the numbers after adding APC into the mix. I use FreeBSD so installing APC is a one liner: cd /usr/ports/www/pecl-APC; sudo make install clean; sudo /usr/local/etc/rc.d/apache.sh restart. Here are the results, up to 15.64 requests / second! Not bad for 5 minutes of work.
Concurrency Level: 10
Time taken for tests: 6.393 seconds
Complete requests: 100
Failed requests: 0
Broken pipe errors: 0
Non-2xx responses: 104
Total transferred: 364892 bytes
HTML transferred: 325580 bytes
Requests per second: 15.64 [#/sec] (mean)
Time per request: 639.30 [ms] (mean)
Time per request: 63.93 [ms] (mean, across all concurrent requests)
Transfer rate: 57.08 [Kbytes/sec] receivedHere are some details about the server Drupal is running on. It is a dual PIII 800Mhz with 1GB of RAM. MySQL runs locally. Hmm… I wonder how much hardware would be required to achieve the same 8.5x performance increase?
{ 1 trackback }
{ 4 comments… read them below or add one }
You should also look into using MySQL 5 if you aren’t, and using MySQL query caching. Drupal makes a lot of repetetive databases requests for the same data, which is why the core needs to make much better use of object caching, ideally with an optional apc backend for that object caching.
Remember that ( on a beefier box ) support.activestate.com is seeing hundreds of requests a second on a pretty heavy page:
Direct against php/apc/one box Requests per second: 190.96 [#/sec] (mean) Time per request: 523.658 [ms] (mean) Time per request: 5.237 [ms] (mean, across all concurrent requests) Transfer rate: 4820.51 [Kbytes/sec] received
You might want to do some profiling with xdebug to see where your machine is spending all of its time.
Your one box does ~ 191 req/sec? That’s pretty fast. I’ll look into MySQL caching as we have another big site (drupal based) that we’re launching and would be good to optimize it as much as possible.
Thanks for the tips!
I would be interested to get a local development server fast. But then, as we know, caching works great mainly for anonymous user. Any advise?
Acronyms (ab? APC?) without explanation are annoying.