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

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

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

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

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

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

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.


PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to