steve roussey wrote:

 > 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

Have you considered using lighttpd with fastcgi loadbalancing and caching using mod_cml (cache meta language)?

We have a similar problem here, and that's how we're going to solve it:

By using lighttpd with fastcgi we seperate the webserver process from php processes (which could even work on other machines) which saves a lot of resources (memory/cpu/load) and enhance response-time for static files.

For simple dynamic requests we can use mod_cml, which can "communicate" with PHP using memcached or the filesystem. Only if mod_cml cannot response to the request using cached data, php is needed. That speeds things up a lot, since cache-hits in mod_cml are not much slower than static files (because php is not touched in any way).

It works perfectly with keep-alive.

The connections from lighttpd process to fastcgi php processes are also persistent. It's no problem to use a php opcode cache. Perhaps db-connection pooling isn't an issue anymore, because the number of php-processes (= number of db connections) can be reduced drastically. Perhaps you can use apc_store()... or memcached to cache results of DB queries.

However, I don't think mod_php on a threaded webserver is a good idea, least of all for a setup under high load because of the arguments already mentioned in this thread and because most developers don't use threaded setups today.

best regards,

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:

Reply via email to