469,963 Members | 1,943 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,963 developers. It's quick & easy.

Connection pooling in PHP ?

PHP Newbie here - I apologize if any of my questions appear daft or
obvious ...

Does PHP (or maybe the web server - Apache in my case), support
(database) connection pooling?. It seems terribly inefficient if every
request for data wil incurr the overhead of creating a connection to the
db.

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?
(pref the latter since it is less "expensive" in computer resource terms)

MTIA

Dec 20 '05 #1
4 14404
NC
Susan Baker wrote:

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?
Depends... PHP can be configured to run as a CGI executable (in which
case, if I remember correctly, each instance will be a separate
process) or as a module of an HTTP server, in which case PHP will
follow the threading model of the HTTP server. So if you run PHP as an
Apache (Apache 1.*, that is) module, each instance of Apache will start
as a separate process; if you run PHP as an ISAPI module under IIS, PHP
will run in threads...
(pref the latter since it is less "expensive" in computer resource
terms)


This may be, but it also means that a malfunction in one thread brings
down the entire process, including all other threads it has spawned...

Cheers,
NC

Dec 20 '05 #2

Susan Baker wrote:
Does PHP (or maybe the web server - Apache in my case), support
(database) connection pooling?. It seems terribly inefficient if every
request for data wil incurr the overhead of creating a connection to the
db.


Sure. Look at the pconnect() family of functions. The exact function
will depend on the database system you're connecting to. For MySQL
it's mysql_pconnect().

pconnect() will leave the connection open when done and reuse idle
connections if available. Be careful, though -- I've seen some weird
problems with connections not being properly closed, especially when a
query blocks.

Although it may seem inefficient to open a new database connection each
time, I'd try both ways (connect() and pconnect()) and see if you
really notice a difference. If you don't, it's probably worth sticking
to plain old connect().

Dec 20 '05 #3
>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
Dec 20 '05 #4
Hello,

on 12/19/2005 11:39 PM Susan Baker said the following:
Does PHP (or maybe the web server - Apache in my case), support
(database) connection pooling?. It seems terribly inefficient if every
request for data wil incurr the overhead of creating a connection to the
db.
Apache supports connection pooling. Just set the MaxClients to a
reasonable limit. If there are more requests, clients will be enqueued.

Actually that is the smart way to achieve PHP database connection pooling.

If you move all static data to a separate server and keep only PHP
scripts that always use database connections in the same server, setting
Apache MaxClients achives the same effect as using a database connection
pooling middleware, except that it will be faster as there is no
middleware delay the communication with the database.

Here you can read more about this:

http://www.meta-language.net/metabas...ve-connections

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?
(pref the latter since it is less "expensive" in computer resource terms)


It depends on the Web server, but multi-threading servers are not
recommended with PHP because some extensions of PHP are not thread-safe.

--

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
Dec 20 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Rob Nicholson | last post: by
1 post views Thread by Lenny Shprekher | last post: by
7 posts views Thread by Mrinal Kamboj | last post: by
3 posts views Thread by Martin B | last post: by
16 posts views Thread by crbd98 | last post: by
20 posts views Thread by fniles | last post: by
3 posts views Thread by fniles | last post: by
15 posts views Thread by Sylvie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.