I work at a company with a high volume web site (you know the drill: LVS directors managing a farm of webservers (with php accelerators) to a few database servers (MySQL if you want to know -- anyone happen to have experience with Emic clustering for MySQL, btw? OK, back on topic...)
PHP4 and Apache1 have served us well in the past. It had flaws (like database connection pooling), but was stable and we had workarounds. There hasn't been much in Apache 2.0 that deserved an upgrade. This is changing. The main item is that we need Keep-Alive connections on the web server. It used to be something that was a nice addition -- images downloaded a little faster, etc. But our new software uses AJAX type stuff and now latency is a fundamental need rather than a nice feature. There is design issue with Apache in that a single connection is tied to a single processes (in Apache1 or Apache2 Prefork) or thread (in Apache2 worker). (BTW: MySQL also has this deficiency). This is changing in Apache 2.1/2.2 with the event MPM. It has a separate thread for each thread group (process) that handles the open Keep-Alive connection. It works very well (though it does require a 2.6 Linux kernel so we'll have lots of upgrades to stage out). Anyone dealing with volume knows that Keep-Alive on Apache1 will kill your setup. Adding web hardware increases the need for db hardware and the whole setup becomes more costly and complicated that it needs to be. The setup we are striving for is to keep connections open all the way down the chain to the database. Ideally this would mean that we would use Apache 2.2 with the event MPM to hold user connections. Then the PHP threads would ideally hold persistent connections to the databases (either through using the Apache 2.1 mod_dbd or doing it in PHP itself). An aside for the moment: while the persistent connection functionality in the mysql extension seems rather useless at first since it its per process and not per server, there is still a use -- when it is used in conjunction with connection pooling software running on the webserver (which keeps its own -- far less -- actual connections open to the db server). The new mysqli extension therefore can't really work with connection pooling as well in this manner and is even less useful than the current situation. Sigh. My ideal also has MySQL breaking the one connection to one thread idea as Apache is doing in the event MPM which would at least reduce the problems with the lack of connection pooling with PHP (though not completely). Almost all of this could be fixed in PHP if it were to run well in a threaded environment. Persistent connection pooling would be easier to accomplish, we could have keep alive turned on all the time. With PHP officially supporting threaded environments the various accelerators would likely support it as well (why isn't this built in to PHP? It is way too pokey without it). I have read and understand that there are a number of issues: 1. Problems with the Apache2 sapi 2. Problems with thread safety in the Zend Engine or PHP itself 3. Problems with thread-safety of modules I don't think it is the PHP developers responsibility to make all modules thread safe themselves (though if the Apache group wanted more people using the worker MPM, they should have considered this option long ago). But it could be possible to fix #1 and #2 (if they are even issues anymore, my research on this is scattered). And there are potential ways to deal with #3. Here are my two suggestions: 1. Make every module that is thread safe add a symbol to denote it as such. Then when making the source we can give a warning about which modules are not thread safe. 2. Create a global extension thread mutex and put all the calls to any extension though it. This will not fix the issue, sadly. But it will accomplish two things: it will reduce the likelyhood of problems and it will make the use of certain extensions slow. So between calling out their name in #1 and making them slow in #2, there might be enough attention on them to convince the maintainers to make them thread-safe. Or maybe not. Please don't take this message in any way other than the thoughts of a webmaster that is dealing with these issues. The desire for low latency is so strong that we may just abondon PHP some day because of it. Maybe someone can hack Apache1 to includes new connection handing? At least for now, another website has lent us their custom software for connection pooling, so even if we degrade its connections to php5 (with PDO or mysqli) we will be OK with just an Apache1 hack. Alas, the Apache group isn't too interested in rewriting parts of Apache1. Who can blame them? Anyone want to backport PDO to PHP4? Well anyhow, thanks for reading and your consideration. Its amazing how one newly popular thing (AJAX stuff in this case) can change our whole view of the software platform landscape. steve -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
