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 directs traffic to an apache 1.3 server just for dynamic pages (very similar to the previous split but using http protocol instead of the fastcgi protocol, or using both approaches)??? OK, thanks for listening to my suggestion. Here is the short version: a) copy the fastcgi apache module to php's source b) make the config options easy for the basic user c) included in future distributions d) make default at a later point e) bring back persistent connections f) remove thread safe code??? maybe crazy idea -steve-- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
