|
Posted by Gordon Burditt on 12/20/05 07:05
>Does PHP (or maybe the web server - Apache in my case), support
>(database) connection pooling?.
Take a look at pconnect(). However, be careful, it's not problem-free.
>It seems terribly inefficient if every
>request for data wil incurr the overhead of creating a connection to the
>db.
If you leave a connection in a funny state, that connection when
allocated to another page can mess up that connection also.
A "funny state" is something that may interfere with pages that
expect a FRESH connection, and don't expect to have, say:
- autocommit turned off
- short timeouts that may have timed out before the new page started
- character set or collation set to something wierd
- sequence problems with a script aborting with a half-fetched
query, followed by another page starting with a new query
One of the problems with pconnect() and apache 1.3 is that you will
shortly end up with one connection per login per Apache child process.
If you routinely can have, say, a peak of 500 Apache processes going,
that may be more connections than your database will handle without
raising the defaults, which chews up more memory. This can be WAY
higher than the number of simultaneous *PHP* processes, depending
on what your webserver is also serving.
I'm not sure what the situation is with Apache 2, which uses threads.
You may have several connections using the same login info due
to demand for more while others are still in use.
>While on the subject of pooling - does any one know (when using PHP in
>"server side scripting") if scripts are launched as seperate processes
>or if they are spawned as threads in a thread pool of a master process?
If PHP is run as a CGI, it's a separate process.
If PHP is run as a module, it depends on the process setup of
apache (in 1.3 it's a child process which may be re-used a hundred
times or so. In 2.* I think it's threads).
Gordon L. Burditt
[Back to original message]
|