Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Having cross-process persistent connection pool for PDO would be great. Having a better system on the DB side would be great too (as it looks to be for Oracle). The MySQL server test looks promising. I like the Apache 2.2 model of using epoll to have one thread handle all the keep-alive connections which in mysql I guess would be sleeping connections. Don't like the one thread per connection system currently, though it has not presented any deal-breaking problems. Well, not yet anyway. :) On 2/6/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Christopher Jones wrote: steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Christopher Jones wrote: I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html Besides there are some third-party solutions like SQLRelay http://sqlrelay.sourceforge.net/ rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
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
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Thanks! That is a blast from the past! I never got it working properly, and since using PHP in FastCGI mode has eliminated the problem by 80%+, hopefully I won't have to revisit it. But thanks again! I never know! -s On 2/7/07, Reinis Rozitis [EMAIL PROTECTED] wrote: Christopher Jones wrote: I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html Besides there are some third-party solutions like SQLRelay http://sqlrelay.sourceforge.net/ rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mod_fast_apache, FastCGI, and mysqli
From my experience with PHP over the years, in setups with both low and high traffic, I'd like to humbly put out a suggestion: have PHP include its own FastCGI SAPI in PHP 5.x and make it the default/recommended in PHP 6. Oh, and allow persistent connections in db apis again (like mysqli). The current FastCGI implementation for Apache has not changed in years (it actually won't compile on the Apache Group's recommended 2.2 version of Apache without end user tweaks). The code is there and it works, though I'm not sure of license compatibility. Though someone must know the protocol well since the PHP side of things was rewritten not long ago. Here are some of the benefits (and some rehash of things for the benefit of people finding this post via Google, et al): 1. FastCGI can be found across almost all web servers, and it factors out the whole threading issue. Threaded web servers can be a great benefit (and the event MPM in Apache 2.2 is a boon to using keep-alive efficiently). 2. In a process based webserver with PHP builtin as a module, every request has the whole php engine there -- even if it is not used (say a static image request, or just hanging around because of a keep-alive request). Each of those processes each hold to their persistent connections for, say, mysql. Which is why its such a bad thing -- all these processes holding open connections even if they aren't going to use them (like the image or keep-alive connection). Its around this point that we start thinking about connection pooling even though that is not needed. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) Now in a Apache 2.0 and FastCGI context (out the hat, say 200 threads per process) we would have 10 processes to split the 2000 threads. Lets say you were wonderful at guessing the size of the PHP FastCGI pool and put it at 50 (same as the number of dynamic requests at this moment in time). You would have 50 connections to mysql as well (moving to fast-cgi really helped here!). In Apache 2.2 with event MPM, we would have one process and 200 threads (with only 71 being in active use). Same PHP process count as Apache 2.0 and same connection count to MySQL. Notice that the PHP FastCGI pool is acting as connection pooling rather effectively for persistent connections. You might have turned that off before, but now you can turn it on and see some return. 3. mysqli: OK, other than the fact that the FastCGI doesn't come preinstalled with either Apache or PHP, and you might have to tweak it to compile for Apache 2.2, you can do the above already today. So why this note? Well, if PHP told everyone via the manual and by integrating a fastcgi module (say mod_fast_apache, mod_fast_apache2, etc), then there likely (ok, hopefully) would have been some positive side effects. Like mysqli having persistent connections. I'm guessing they aren't there because people wanted to protect users from using them with a process based webserver like Apache1.3. Dumb users, it doesn't help them, only makes it worse. Yes, true, assuming people using mod_apache. Change the assumption, and maybe different things happen. Hmm, this is a lot to write when I could have said give us back persistent connections!... 4. Setting up FastCGI is horrible/ugly. Creating a fastcgi module for apache that only deals with PHP on the other end, gives a bit of leeway on how to do configuration stuff. Perhaps make FastCGi-PHP as easy to config as mod_apache. Thus calling it mod_fast_apache. People will be drawn to the word fast, btw :p 5. FastCGI is a far better base from which to deal with security for PHP, even if not addressed by PHP. Jails, having different processes for different users, etc. The latter doesn't interest me at all, but the former does. It need not be a security play, but it would give a better base from which to start. Well, my opinion, anyway. 6. I preface this with I don't know what I'm talking about here: is all the thread safe code in php really necessary? My experience is that FastCGI is both more stable and faster. Is php used in embedded threaded environments? Or was the the threading just for use on Windows, where we can better use FastCGI? Is there something to be gained by removing it? OMG, am I still writing? Somewhat off topic: Having the webserver and php run on the same machine is rather a poor mans way of scaling. Does anyone have stats on how well chained processing compares? (Like separating the web server and the PHP onto separate machines, or setup with a proxy server that
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) The oci8 extension lets you timeout idle persistent connections. Unrelated to your FastCGI suggestion but FYI on database connection pooling: http://blogs.oracle.com/opal/2007/01/03. The pooling described has no dependency on how you deploy your application and works across multiple application types connecting to the DB. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Christopher Jones wrote: steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
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. 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. The best reason for FastCGI, and why you won't find anyone saying it is a bad thing to support, is for shared hosting services to better separate users in system-level jails. 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. 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. And I actually know a little bit about running PHP in extremely high-traffic situations. -Rasmus steve wrote: From my experience with PHP over the years, in setups with both low and high traffic, I'd like to humbly put out a suggestion: have PHP include its own FastCGI SAPI in PHP 5.x and make it the default/recommended in PHP 6. Oh, and allow persistent connections in db apis again (like mysqli). The current FastCGI implementation for Apache has not changed in years (it actually won't compile on the Apache Group's recommended 2.2 version of Apache without end user tweaks). The code is there and it works, though I'm not sure of license compatibility. Though someone must know the protocol well since the PHP side of things was rewritten not long ago. Here are some of the benefits (and some rehash of things for the benefit of people finding this post via Google, et al): 1. FastCGI can be found across almost all web servers, and it factors out the whole threading issue. Threaded web servers can be a great benefit (and the event MPM in Apache 2.2 is a boon to using keep-alive efficiently). 2. In a process based webserver with PHP builtin as a module, every request has the whole php engine there -- even if it is not used (say a static image request, or just hanging around because of a keep-alive request). Each of those processes each hold to their persistent connections for, say, mysql. Which is why its such a bad thing -- all these processes holding open connections even if they aren't going to use them (like the image or keep-alive connection). Its around this point that we start thinking about connection pooling even though that is not needed. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) Now in a Apache 2.0 and FastCGI context (out the hat, say 200 threads per process) we would have 10 processes to split the 2000 threads. Lets say you were wonderful at guessing the size of the PHP FastCGI pool and put it at 50 (same as the number of dynamic requests at this moment in time). You would have 50 connections to mysql as well (moving to fast-cgi really helped here!). In Apache 2.2 with event MPM, we would have one process and 200 threads (with only 71 being in active use). Same PHP process count as Apache 2.0 and same connection count to MySQL. Notice that the PHP FastCGI pool is acting as connection pooling rather effectively for persistent connections. You might have turned that off before, but now you can turn it on and see some return. 3. mysqli: OK, other than the fact that the FastCGI doesn't come preinstalled with either Apache or PHP, and you might have to tweak it to compile for Apache 2.2, you can do the above already today. So why this note? Well, if PHP told
