First off, I know I said I was going to try lighhtpd: the site I'm
testing this on has so many rewrite rules, I just didn't have enough
ambition...
That said, the end result is that I put Apache1/mod_php4 up against
Apache2/FastCGI/PHP4. Well, under real load both did about the same.
The Apache2 setup averaged a smaller "load average" as defined by top.
;) It also used more memory. More on that later. But overall, they
performed about the same.
The same, except that the Apache2 setup could leave KeepAlive turned
on. It's status also shows how many threads are in Keep-Alive and
Close states (with Apache1 would have shown the close state), which is
nice. It is still one thread to one connection pairing (unlike the
event mpm to be in apache2.2), but even so, that is much better one
user connection to one PHP process, IMHO. I liked the snappiness of
the site much better so I went ahead and migrated it. Works great.
I've read where other people have put a small web farm behind a load
balancer and then load balanced them to a larger pool of PHP servers
with no webserver on those machines at all. I suppose that would work
well for sites that have a good mix of static and lots of dynamic
content. It would take some experience to figure out how to propery
manage that. Probably the next step for me to worry about for another
site -- one that is truly large but not really ready to go with
separate domains for images or akamai.
There are some downsides:
-
At least the way I have it setup, I have a fixed set of PHP
processes (PHP_FCGI_CHILDREN) always running and that has to be enough
to deal with peak load when not all webservers are in production. That
leads to higher memory use under non-peak conditions. On the other
side, when peak traffic comes in, the memory usage isn't as much as a
swing from low to high traffic. -
I haven't had much luck getting information on how opcode caches
work to know what the benefits and drawbacks of trying more than one
FastCGI PM. Or anything about such acceleration and FastCGI. It does
appear to work, though, so I guess I should just be happy. -
Be careful of starting and stopping apache too quickly -- the PHP
processes don't notice all that fast and you can end up with too many
yet none working. -
I can't prove it just yet, but I swear FastCGI is buffering
somehow, and using a much smaller buffer than the big TCP buffers I
have set. I don't remember end users' browsers getting small chunks in
chunked encoding before. I swear they used to jet out in a single
chunk when on broadband. Maybe I just don't remember correctly. Now I
have to go back to mod_php to test it. Grr. -
Oh yeah, documentation is abysmal.
Overall, I find it much better. :)
-steve