Well,
after a weekend of testing I found that:
- fastcgi (using zend core fastcgi and other fastcgi) didn't give me better
results than using the mod_php, I couldn't test using IIS since I don't have
it =P
- apc and xcache with fastcgi gave always trouble when benchmarking using ab
from apache (php crashed all the times).
- turning off apc.stat really boost my code, but I had to change some things
(relative require_once to absolute require_once using dirname(__FILE__))
- it seems that even if apc.stat is turned off, it access the disk (well,
obviously it does the first time it caches the files) because ramdisk still
faster than using my files on my harddrive, it should be faster only the
first time, but it's faster all the times (I checked out apc.php and I found
that apc was already caching the files).
- concluding, I'll use here in my dev laptop mod_php + apc with apc.filters
filtering and caching only ZF files (in a ramdisk) and my customers windows
servers I'll use mod_php + apc with apc.stat always off (maybe including the
ramdisk thingy).
Times:
- fastcgi ~700ms
- fastcgi + accelerator (apc or xcache) ~ 600ms
- mod_php alone ~ 500ms
- mod_php + apc + files in ramdisk ~ 300ms
- mod_php + apc + apc.stat = 0 ~ 300ms
- mod_php + apc + apc.stat = 0 + files in ramdisk ~ 110ms
- mod_php + apc + apc.stat = 0 + apc.filtering (only caching ZF) + files in
ramdisk (only ZF) ~ 280ms
Again my setup is:
- apache 2.2 (mod_php)
- php 5.2.5
- apc 3.0.17-dev
- zf 1.5.1
- windows xp home
Still sucks, doesn't it :P
btw, I couldn't any documentation about apc caching classes (maybe you were
talking about user cache), the command I use to benchmark was:
ab -c 5 -n 20 http://localhost/xxxxx/ (before running this command I opened
twice the page in order that apc cached w/o fragmenting the files)
The page I used did connect to a DB but doing nothing but a 'SET NAMES utf8'
query, and disabling it didn't show any difference.
Aldemar
----- Original Message -----
From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, April 05, 2008 6:10 PM
Subject: Re: [fw-general] ZF - APC tuning
-- Aldemar Bernal <[EMAIL PROTECTED]> wrote
(on Saturday, 05 April 2008, 02:40 PM -0500):
I've been trying to make my app perform better, every request takes
(according
ab: apache stress tool) ~510ms, which is a lot!, over half second in
every
request?, so I installed and enabled APC but surprisly it performed even
worst
than w/o APC, ~650ms per request. Any of you have tried using APC w/ ZF?
The best results I had was using a RAM Disk, putting in it only zf it
perform
~420ms and w/ the app ~330ms.
My setup is:
- apache 2.2
- php 5.2.5
- apc 3.0.17-dev
- zf 1.5.1
- windows xp home
With the best configuration (zf and app running from ram disk) and using
apc
returns the same results ~330ms (so, no difference at all when using it
from a
ramdisk).
A few things to note.
First, I'm assuming you're using apache with mod_php. On windows, my
understanding is that this simply doesn't perform terribly well. You may
get better results with IIS+FastCGI (heck, you might try FastCGI with
apache to see if that goes better, too). Regardless, Windows and Mac
environments tend not to get you your best performance, though.
Second, IIRC, APC allows you to preload classes. I'd recommend
investigating that option.
Third, how many requests are you benching? You need to run a fair number
of requests with APC to ensure that the cache gets loaded and that
you're actually hitting the cache (one or two requests simply won't do
it). You may be already doing this, but you don't indicate that fact in
your description.
Also, are you using a DB? or any web services? These may also be
contributing to the lag you're seeing.
I've benched some barebones apps in the past, as has Paul M. Jones, and
the fact of the matter is that frameworks tend to be performance hogs,
even when serving simple "Hello World" style pages. That said, being
able to handle only 1 or 2 requests per second sounds seriously slow,
and I know that most apps I've done with ZF perform much better than
that... particularly when using good caching strategies and not hitting
a DB or web service.
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
