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
itself).
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.
http://trac.lighttpd.net/trac/wiki/CacheMetaLanguage
http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP
http://trac.lighttpd.net/trac/wiki/MigratingFromApache
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,
Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
