If persistent connections don't have any added functionality,
what are they good for?
The answer here is extremely simple -- efficiency. Persistent
connections are good if the overhead to create a link to
your SQL server is high. Whether or not this overhead is
really high depends on many factors. Like, what kind of
database it is, whether or not it sits on the same computer
on which your web server sits, how loaded the machine the
SQL server sits on is and so forth. The bottom line is that
if that connection overhead is high, persistent connections
help you considerably. They cause the child process to simply
connect only once for its entire lifespan, instead of every
time it processes a page that requires connecting to the
SQL server. This means that for every child that opened
a persistent connection will have its own open persistent
connection to the server. For example, if you had 20 different
child processes that ran a script that made a persistent
connection to your SQL server, you'd have 20 different connections
to the SQL server, one from each child.
Note, however, that this can have some drawbacks if you
are using a database with connection limits that are exceeded
by persistent child connections. If your database has a
limit of 16 simultaneous connections, and in the course
of a busy server session, 17 child threads attempt to connect,
one will not be able to. If there are bugs in your scripts
which do not allow the connections to shut down (such as
infinite loops), the database with only 16 connections may
be rapidly swamped. Check your database documentation for
information on handling abandoned or idle connections.
Warning
There are a couple of additional caveats to keep in mind
when using persistent connections. One is that when using
table locking on a persistent connection, if the script
for whatever reason cannot release the lock, then subsequent
scripts using the same connection will block indefinitely
and may require that you either restart the httpd server
or the database server. Another is that when using transactions,
a transaction block will also carry over to the next script
which uses that connection if script execution ends before
the transaction block does. In either case, you can use
register_shutdown_function() to register a simple cleanup
function to unlock your tables or roll back your transactions.
Better yet, avoid the problem entirely by not using persistent
connections in scripts which use table locks or transactions
(you can still use them elsewhere).
An important summary. Persistent connections were designed
to have one-to-one mapping to regular connections. That
means that you should always be able to replace persistent
connections with non-persistent connections, and it won't
change the way your script behaves. It may (and probably
will) change the efficiency of the script, but not its behavior!
See also fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(),
ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(),
ociplogon(), odbc_pconnect(), ora_plogon(), pfsockopen(),
pg_pconnect(), and sybase_pconnect().
