On 2/6/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
A couple of points. mysqli doesn't have persistent connections because the authors of that particular extension don't think it is a good idea. It's not a PHP-wide thing, PDO and others do have it.
Yes, point taken. I just figured they were trying to fix an issue that people happened upon since most just use Apache 1.3 with mod_apache.
If you are going to FastCGI for performance and scalability reasons because you don't want a heavyweight web server process handle a dynamic request, then you are essentially just using the web server as a proxy which isn't really what it was written to be. There are much more effective reverse proxies out there that can do that. Let's not get carried away and make it out to be the solution to everything, because it certainly isn't. The larger companies have Akamai or Akamai-like solutions for all their static file needs, and most of the smaller ones have thttpd or lighhttpd lightweight servers handling those or they have stuck Squid or Pound out in front. For these sorts of architectures the extra handoff to a FastCGI process doesn't make much sense because every request that gets through to the web server is going to be a dynamic one so Apache1 or Apache2-prefork is managing these process-based PHP interpreters in exactly the same fashion that FastCGI would with the exception that you have more control with the richness of Apache and you are closer to the actual request and can make use of the rich set of Apache modules out there.
Hmmm. Using a reverse proxy like Pound will still connect to PHP via a webserver since PHP will be wrapped up in Apache. Maybe running apache this way doesn't add much overhead. I have not done this setup, so I am ignorant to the particulars. But I'm not sure if Pound would hold open the keep-alives (with 2000 open threads?) or if that would go all the way through to the apache (where there would now be 2000 processes). Having Keep-Alive off does simplify things greatly, but I am assuming it is there. :) Just an FYI: I have two setups that I have to deal with: LVS servers -> Apache servers -> LVS -> PHP servers -> DB servers Here the LVS servers act as firewall and load balancer (level-4 switching in kernel mode), and the Apache servers talk to the PHP servers via FastCGI. We are going to change the Apache servers to lighttpd servers to avoid the need for the middle lvs since lighttpd can load balance fastcgi and that middle lvs has no backup. <cough> And lighttpd deals with keep-alives ok as far as I know. My setup is: LVS servers -> Apache / PHP servers -> DB servers This setup has PHP running on the same servers as Apache communicating via FastCGI. Having Keep-Alive turned on, I can't think of how to handle many simultaneous connections. Servering static content isn't really the issue, though it contributes. Its having all those sleeping connections. I only know that LVS does a great job with them and Apache 2.2 event MPM does a good job. So that is where I'm coming from. Hopefully I sound less nutty.
So yes, for the ISP case, I am all for suggesting that FastCGI should be the default way to run PHP. We've been saying that for a while actually. But in other cases you are going to have a much harder time convincing me.
A. Small web server case: not much different performance wise to use FastCGI B. Using Keep-Alive on a small server starts causing problems for noobs that use persistent connections, using FastCGI doesn't. C. Load balanced multiple server medium sized site like above gets lots of benefits, including speed, less resource usage (fewer servers!) use of both persistent db connections and persistent http connections. D. ISP's use FastCGI for security issues. (so should we all). E. Large sites use Akamai, don't have their people worrying that adding servers comes out of their paychecks, can basically do any number of configurations, efficient or not, and have labs to test such arrangements. OK, I sound jealous here.... Not to mention, the module specific stuff would be identical for all groups above. And the fastCGI module for apache has already fallen into disrepair. I like the idea of PHP taking it rather than apache, as it could be made into a PHP only fastcgi module and have easier options for users. And maybe get fastcgi load balancing like lighttpd.
And I actually know a little bit about running PHP in extremely high-traffic situations.
And thank you for your insights!!! Particularly if you have advice on scaling COMET type connections with data from PHP. That is a whole other story... steve -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
