APC and Web Application Performance
Well i’ve managed to get a lot more performance out of my framework, thanks to APC.
First, I benchmarked the website before installing APC and doing any tweaks:
# ab2 -k -c 50 -t 300 http://devwww.(hidden).net/user/1/ > pre_opt.txt
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking devwww.(hidden).net (be patient)
Server Software: Apache
Server Hostname: devwww.(hidden).net
Server Port: 80
Document Path: /user/1/
Document Length: 16410 bytes
Concurrency Level: 50
Time taken for tests: 300.399 seconds
Complete requests: 25668
Failed requests: 12730
(Connect: 0, Length: 12730, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 12618
Total transferred: 247874835 bytes
HTML transferred: 240597628 bytes
Requests per second: 85.56 [#/sec] (mean)
Time per request: 584.386 [ms] (mean)
Time per request: 11.688 [ms] (mean, across all concurrent requests)
Transfer rate: 806.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 2.5 0 176
Processing: 12 582 372.1 544 5564
Waiting: 12 381 358.2 265 5064
Total: 12 582 372.2 544 5564
Percentage of the requests served within a certain time (ms)
50% 544
66% 685
75% 779
80% 840
90% 1022
95% 1215
98% 1501
99% 1748
100% 5564 (longest request)
Very average, I think you’ll agree.
Lets install APC. Directions are well documented at the link 
Once APC was installed and running, lets try that again:
# ab2 -k -c 50 -t 300 http://devwww.(hidden).net/user/1/ > post_apc_inst_no_db.txt
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking devwww.(hidden).net (be patient)
Server Software: Apache
Server Hostname: devwww.(hidden).net
Server Port: 80
Document Path: /user/1/
Document Length: 16410 bytes
Concurrency Level: 50
Time taken for tests: 300.3581 seconds
Complete requests: 37226
Failed requests: 19643
(Connect: 0, Length: 19643, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 19459
Total transferred: 342638118 bytes
HTML transferred: 332252980 bytes
Requests per second: 124.09 [#/sec] (mean)
Time per request: 402.949 [ms] (mean)
Time per request: 8.059 [ms] (mean, across all concurrent requests)
Transfer rate: 1115.34 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.2 0 69
Processing: 5 402 261.4 370 2841
Waiting: 0 267 245.3 190 2730
Total: 5 402 261.4 370 2841
Percentage of the requests served within a certain time (ms)
50% 370
66% 477
75% 548
80% 595
90% 731
95% 866
98% 1038
99% 1192
100% 2841 (longest request)
Still lots of errors, but still faster. Perhaps I shouldnt be doing so many requests at a time Ill have to come up with a better test that doesn’t hammer the system so much..
That page is pretty database intensive as well, and I’ve been attempting to use the APC variable caching features to speed that part of the site up as well but running into issues with PDO and APC, throwing an exception with the following message: ‘You cannot serialize or unserialize PDOStatement instances’ when saving the resultset into the cache. Also, still yet to experiment with gz encoding pages, but i’m a little concerned that will raise the load averages of the site compressing the pages on the way out..
More optimization to come, stay tuned.
Comments
Comment from Sebs
Date: September 20, 2007, 11:29 pm
Well i’ve managed to get 60 Extra hours working timne a wekk, thanks to apc .14 
Consider compile cvs head and save some extra weekends
Comment from Alexey Zakhlestin
Date: September 20, 2007, 11:37 pm
I would also advice to give http://xcache.lighttpd.net/ a try. It works more stable than APC for me. Regarding PDO statements vs. cache, if you really care about performance I would advice using ->fetchAll() and caching the result-array. fetching by row makes additional load on database
Comment from Mike
Date: September 21, 2007, 5:18 am
Looks like all of your errors are length errors and as such, most likely, not errors at all.
If the pages you are hammering have dynamic content that may change on each request, you’ll get length errors. So, nothing to worry about there.
Comment from vortex
Date: September 21, 2007, 6:27 am
@Jedrek: Of course Thanks for the heads up!
@Alexey: Thanks fpr the suggestion, but I’ll see how APC goes for now. This project isn’t ready for production yet so i’ll re-evaluate once the time to go live comes.
@Mike: Ahh yes of course.
Pingback from vortex’s blog » APC and Web Application Performance, take 2
Date: September 21, 2007, 8:44 am
[...] After encountering a few issues while implementing APC into my framework which uses PDO in its ORM system, I have managed to overcome these issues and successfully cache result sets. Previous issues were outlined in the article ‘APC and Web Application Performance‘ [...]
Comment from Guru
Date: September 21, 2007, 6:30 pm
the mistake is on line 4.5, even a 5th grader would have got that one.
Comment from Jedrek
Date: September 20, 2007, 11:24 pm
‘You cannot serialize or unserialize PDOStatement instances’ - please read PHP manual - “It is not possible to serialize PHP built-in objects.” (http://pl.php.net/serialize)
Same thing will happen when you want serialize SimpleXML, DataTime etc objects.