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: 1. 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. 2. 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. 3. 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. 4. 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. 5. Oh yeah, documentation is abysmal. Overall, I find it much better. :) -steve-- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
