mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 08:28:54 +00:00
150 lines
7 KiB
XML
150 lines
7 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!-- $Revision$ -->
|
|
<chapter xml:id="features.persistent-connections" xmlns="http://docbook.org/ns/docbook">
|
|
<title>Persistent Database Connections</title>
|
|
|
|
<simpara>
|
|
Persistent connections are links that do not close when the
|
|
execution of your script ends. When a persistent connection is
|
|
requested, PHP checks if there's already an identical persistent
|
|
connection (that remained open from earlier) - and if it exists, it
|
|
uses it. If it does not exist, it creates the link. An 'identical'
|
|
connection is a connection that was opened to the same host, with
|
|
the same username and the same password (where applicable).
|
|
</simpara>
|
|
<simpara>
|
|
People who aren't thoroughly familiar with the way web servers work
|
|
and distribute the load may mistake persistent connects for what
|
|
they're not. In particular, they do <emphasis>not</emphasis> give
|
|
you an ability to open 'user sessions' on the same link, they
|
|
do <emphasis>not</emphasis> give you an ability to build up a
|
|
transaction efficiently, and they don't do a whole lot of other
|
|
things. In fact, to be extremely clear about the subject,
|
|
persistent connections don't give you <emphasis>any</emphasis>
|
|
functionality that wasn't possible with their non-persistent
|
|
brothers.
|
|
</simpara>
|
|
<simpara>
|
|
Why?
|
|
</simpara>
|
|
<simpara>
|
|
This has to do with the way web servers work. There are three ways
|
|
in which your web server can utilize PHP to generate web pages.
|
|
</simpara>
|
|
<simpara>
|
|
The first method is to use PHP as a CGI "wrapper". When run this
|
|
way, an instance of the PHP interpreter is created and destroyed
|
|
for every page request (for a PHP page) to your web server.
|
|
Because it is destroyed after every request, any resources that it
|
|
acquires (such as a link to an SQL database server) are closed when
|
|
it is destroyed. In this case, you do not gain anything from trying
|
|
to use persistent connections -- they simply don't persist.
|
|
</simpara>
|
|
<simpara>
|
|
The second, and most popular, method is to run PHP as a module in a
|
|
multiprocess web server, which currently only includes Apache. A
|
|
multiprocess server typically has one process (the parent) which
|
|
coordinates a set of processes (its children) who actually do the
|
|
work of serving up web pages. When a request comes in from a
|
|
client, it is handed off to one of the children that is not already
|
|
serving another client. This means that when the same client makes
|
|
a second request to the server, it may be served by a different
|
|
child process than the first time. When opening a persistent connection,
|
|
every following page requesting SQL services can reuse the same
|
|
established connection to the SQL server.
|
|
</simpara>
|
|
<simpara>
|
|
The last method is to use PHP as a plug-in for a multithreaded web
|
|
server. Currently PHP has support for WSAPI, and NSAPI (on
|
|
Windows), which all allow PHP to be used as a plug-in on multithreaded
|
|
servers like Netscape FastTrack (iPlanet), Microsoft's Internet Information
|
|
Server (IIS), and O'Reilly's WebSite Pro. The behavior is essentially
|
|
the same as for the multiprocess model described before.
|
|
</simpara>
|
|
<simpara>
|
|
If persistent connections don't have any added functionality, what
|
|
are they good for?
|
|
</simpara>
|
|
<simpara>
|
|
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.
|
|
</simpara>
|
|
<simpara>
|
|
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.
|
|
</simpara>
|
|
<warning>
|
|
<simpara>
|
|
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 <function>register_shutdown_function</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).
|
|
</simpara>
|
|
</warning>
|
|
<simpara>
|
|
An important summary. Persistent connections were designed to have
|
|
one-to-one mapping to regular connections. That means that you
|
|
should <emphasis>always</emphasis> be able to replace persistent
|
|
connections with non-persistent connections, and it won't change
|
|
the way your script behaves. It <emphasis>may</emphasis> (and
|
|
probably will) change the efficiency of the script, but not its
|
|
behavior!
|
|
</simpara>
|
|
<para>
|
|
See also <function>ibase_pconnect</function>, <function>ociplogon</function>,
|
|
<function>odbc_pconnect</function>, <function>oci_pconnect</function>,
|
|
<function>pfsockopen</function>, and <function>pg_pconnect</function>.
|
|
</para>
|
|
</chapter>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode: sgml
|
|
sgml-omittag:t
|
|
sgml-shorttag:t
|
|
sgml-minimize-attributes:nil
|
|
sgml-always-quote-attributes:t
|
|
sgml-indent-step:1
|
|
sgml-indent-data:t
|
|
indent-tabs-mode:nil
|
|
sgml-parent-document:nil
|
|
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
|
|
sgml-exposed-tags:nil
|
|
sgml-local-catalogs:nil
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
vim600: syn=xml fen fdm=syntax fdl=2 si
|
|
vim: et tw=78 syn=sgml
|
|
vi: ts=1 sw=1
|
|
-->
|