I’ve spent a good amount of time messing with Apache today, trying to tweak performance out of it. After attempting to run Apache Benchmark against this WordPress install (both remote and local), I noticed I was topping out at 13-14 requests per second.
Strangeness, indeed.
I spent about 15 minutes messing around before I discovered that all I was getting back with AB was some headers. For some reason, apache was having a hell of a time returning the headers. Strangeness. This time I then ran AB against my APC Status script. 400 requests/second. That’s far more reasonable than 13-14 requests per second.
What the hell is going on?
I still haven’t figured that part out yet.
Running ab -n 100 -c 10 http://www.geeklan.com/ still only returns 13-14 requests per second. I can tell the site is running better than that, but AB just isn’t getting to it. It’s literally only able to pull down headers. If I kick off a wget against the domain it pulls down proper, fully-loaded index.
I’ll be working on this a bit more tonight - maybe I’ll figure out why it’s misbehaving.
And no, specifying geeklan.com/index.php doesn’t help.
UPDATE:
This is very interesting. When utilizing AB, I get this in the log file;
[Fri Feb 22 22:25:00 2008] [error] [client 64.41.145.110] PHP Warning: sem_release(): supplied argument is not a valid SysV semaphore resource in ***/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 116
(*** is me hiding the real path)
UPDATE 2:
Fixed that by setting $use_flock to TRUE in the wp-cache-config.php file. This still has not fixed what apache responds with to AB. There are now no entries in the error log. I’m completely stumped at this point.
UPDATE 3:
Okay, now THIS is weird. I sat back for a second and thought, ‘Okay, so ab doesn’t show what it’s getting as headers.. AH HAH! strace!’
Here’s what I ran (and an excerpt from the log):
strace -o trace.log ab -n 1 -c 1 http://www.geeklan.com/
And the output that caught my eye;
write(4, “GET / HTTP/1.0\r\nHost: www.geekla”…, 90) = 90
read(4, “HTTP/1.0 301 Moved Permanently\r\n”…, 8192) = 255
Now THAT has me stumped. wget, links, lynx nor any browser I can throw at geeklan.com catches a 301 Redirect off of the page and I know that WordPress doesn’t do any form of retarded redirects (let alone a 301). This sorta smells like an apache issue, but I’d see the same if I ran it against test.php or some of my other benchmark files. This happens even if I specify /index.php
Blech.
UPDATE 4 (Final):
Turns out it was, in fact, wordpress. I’ve got WordPress setup to run as http://geeklan.com/ and requests to http://www.geeklan.com/ were 301′d to http://geeklan.com/. Ugh. At least I know what was up. Here are some fun stats from Apache Benchmark:
ab -n 1000 -c 100 http://geeklan.com/
Requests per second: 384.43 [#/sec] (mean)
Time per request: 260.122 [ms] (mean)
Time per request: 2.601 [ms] (mean, across all concurrent requests)
leave a reply