[PHP-DOC] cvs: phpdoc /it/features persistent-connections.xml From: Luca Perugini (l.perugini <email protected>)
Date: 08/31/00

perugini Thu Aug 31 08:36:16 2000 EDT

  Modified files:
    /phpdoc/it/features persistent-connections.xml
  Log:
  In Sync with en tree.
  
  
Index: phpdoc/it/features/persistent-connections.xml
diff -u phpdoc/it/features/persistent-connections.xml:1.1 phpdoc/it/features/persistent-connections.xml:1.2
--- phpdoc/it/features/persistent-connections.xml:1.1 Sat Dec 18 17:00:07 1999
+++ phpdoc/it/features/persistent-connections.xml Thu Aug 31 08:36:16 2000
@@ -1,5 +1,5 @@
  <chapter id="features.persistent-connections">
- <title>Persistent database connections</title>
+ <title>Persistent Database Connections</title>
 
   <simpara>
    Persistent connections are SQL links that do not close when the
@@ -8,8 +8,8 @@
    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>
-
+ 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
@@ -17,79 +17,96 @@
    you an ability to open 'user sessions' on the same SQL link, they
    do <emphasis>not</emphasis> give you an ability to build up a
    transaction efficently, 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>
-
+ 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>
-
+ 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>
-
+ 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>
-
+ 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
+ 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 each request comes in from a 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 serviced by a different child process
- than the first time. What a persistent connection does for you in
- this case it make it so each child process only needs to connect to
- your SQL server the first time that it serves a page that makes us of
- such a connection. When another page then requires a connection to the
- SQL server, it can reuse the connection that child established earlier.</simpara>
-
+ coordinates a set of processes (its children) who actually do the
+ work of serving up web pages. When each request comes in from a 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 serviced by a different
+ child process than the first time. What a persistent connection
+ does for you in this case it make it so each child process only
+ needs to connect to your SQL server the first time that it serves a
+ page that makes us of such a connection. When another page then
+ requires a connection to the SQL server, it can reuse the
+ connection that child established earlier.
+ </simpara>
   <simpara>
    The last method is to use PHP as a plug-in for a multithreaded web
    server. Currently this is only theoretical -- PHP does not yet work
    as a plug-in for any multithreaded web servers. Work is progressing
- on support for ISAPI, WSAPI, and NSAPI (on Windows), which will
- all allow PHP to be used as a plug-in on multithreaded servers like
+ on support for ISAPI, WSAPI, and NSAPI (on Windows), which will all
+ allow PHP to be used as a plug-in on multithreaded servers like
    Netscape FastTrack, Microsoft's Internet Information Server (IIS),
    and O'Reilly's WebSite Pro. When this happens, the behavior will be
- essentially the same as for the multiprocess model described before.</simpara>
-
+ 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>
-
+ 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>
-
+ 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 persistant
+ 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), a database with only 32 connections
+ may be rapidly swamped. Check your database documentation for
+ information on handling abandoned or idle connections.
+ </simpara>
   <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>
+ 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>
 
  </chapter>
 
@@ -103,7 +120,7 @@
 sgml-indent-step:1
 sgml-indent-data:t
 sgml-parent-document:nil
-sgml-default-dtd-file:"../manual.ced"
+sgml-default-dtd-file:"../../manual.ced"
 sgml-exposed-tags:nil
 sgml-local-catalogs:nil
 sgml-local-ecat-files:nil