What sort of caching do you have running with WordPress?

@jefe78:

MaxRequestsPerChild 100
It's probably not the source of your woes, but this seems excessively low.

@Emufarmers:

What sort of caching do you have running with WordPress?

@jefe78:

MaxRequestsPerChild 100
It's probably not the source of your woes, but this seems excessively low.

Hey Emufarmers, I'm not entirely sure as our developer is handling Wordpress but I know he's caching heavily.

What is a more appropriate MaxRequestsPerChild value?

@jefe78:

Hey Emufarmers, I'm not entirely sure as our developer is handling Wordpress but I know he's caching heavily.
You should probably ask him for some specifics. The benchmark results you're getting are the sort I'd expect from Web software that's running without caching.

@jefe78:

What is a more appropriate MaxRequestsPerChild value?
Something like 500 or 1000 or higher would probably be sensible, unless you're noticing significant memory leaks.

@Emufarmers:

@jefe78:

Hey Emufarmers, I'm not entirely sure as our developer is handling Wordpress but I know he's caching heavily.
You should probably ask him for some specifics. The benchmark results you're getting are the sort I'd expect from Web software that's running without caching.

@jefe78:

What is a more appropriate MaxRequestsPerChild value?
Something like 500 or 1000 or higher would probably be sensible, unless you're noticing significant memory leaks.

I checked and we're running db-cache-reloaded & w3-total-cache. I've been hitting it off and on and we're still only getting 0.43 requests per second. Something seems to be bottlenecked to me.

@jefe78:

Concurrency Level: 1

There's your problem. You tested with no concurrency whatsoever, which will obviously produce very low results while most of your apache processes sit idle.

@Guspaz:

@jefe78:

Concurrency Level: 1

There's your problem. You tested with no concurrency whatsoever, which will obviously produce very low results while most of your apache processes sit idle.

Gotcha. I'll fix that and try again!

New results:

ab -c 20 -t 10 "http://173.255.238.110/"

This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 173.255.238.110 (be patient)

Finished 1 requests

Server Software: Apache/2.2.14

Server Hostname: 173.255.238.110

Server Port: 80

Document Path: /

Document Length: 67619 bytes

Concurrency Level: 20

Time taken for tests: 25.956 seconds

Complete requests: 1

Failed requests: 0

Write errors: 0

Total transferred: 1358078 bytes

HTML transferred: 1351798 bytes

Requests per second: 0.04 #/sec

Time per request: 519119.300 ms

Time per request: 25955.965 [ms] (mean, across all concurrent requests)

Transfer rate: 51.10 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 26 26 0.0 26 26

Processing: 25930 25930 0.0 25930 25930

Waiting: 6658 6658 0.0 6658 6658

Total: 25956 25956 0.0 25956 25956

Would something more appropriate be:

ab -c 20 -t 10 -n 1000 "HOST"?

Sure, but I'd agree at this point that your benchmark results do show a serious bottleneck somewhere.

Your Apache configuration looks good to me, although I'm not an expert in that (I don't use Apache). You said you've already got WP caches going, so that seems to be covered… I think at this point you need to try to deduce where the bottleneck is. For example, try running 'top' while doing a lengthy ab test and seeing if anything is maxing out the CPU, or if iowait is really high, etc. If Apache is eating up all the CPU time, try fastcgi, which will split out PHP into separate processes, which will let you identify if PHP is the culprit. If it is, a PHP cache can help slightly. If the database is at fault, then tweaking the database server might be warranted.

If w3-total-cache doesn't handle php caching, then apc (php cache) would probably help a lot.