tom Wed May 22 17:40:19 2002 EDT
Modified files:
/phpdoc-de/features persistent-connections.xml
Log:
sync to en
Index: phpdoc-de/features/persistent-connections.xml
diff -u phpdoc-de/features/persistent-connections.xml:1.7
phpdoc-de/features/persistent-connections.xml:1.8
--- phpdoc-de/features/persistent-connections.xml:1.7 Wed Dec 12 15:46:06 2001
+++ phpdoc-de/features/persistent-connections.xml Wed May 22 17:40:19 2002
@@ -1,4 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
+<!-- EN-Revision: 1.19 Maintainer: tom Status: ready -->
<chapter id="features.persistent-connections">
<title>Persistente Datenbankverbindungen</title>
@@ -12,103 +13,147 @@
'identische' Verbindung ist eine Verbindung, die zu dem
gleichen Host mit dem gleichen Usernamen und Passwort
hergestellt wurde.</simpara>
-
- <simpara>
- Wer nicht durchg�ngig mit der Art und Weise, wie
- Webserver arbeiten und die Last verteilen, vertraut ist, k�nnte
- missverstehen, wof�r persistente Verbindungen gedacht sind.
- Im Besonderen bieten sie <emphasis>keine</emphasis>
- M�glichkeit, 'Benutzersitzungen' auf der gleichen SQL-Verbindung
- zu �ffnen und <emphasis>keine</emphasis> M�glichkeit, eine
- Transaktion aufzubauen, und sie k�nnen viele
- andere Sachen nicht. Um absulute Klarheit zu schaffen:
- Persistente Verbindungen bieten <emphasis>keine</emphasis>
- Funktionalit�t, die nicht auch von nicht-persistenten Verbindungen
- bereitgestellt wird.</simpara>
-
+ <note>
+ <para>
+ Auch andere Erweiterungen bieten persistente Verbindungen, wie z.B.
+ <link linkend="ref.imap">IMAP extension</link>.
+ </para>
+ </note>
+ <simpara>
+ Wer nicht durchg�ngig mit der Art und Weise vertraut ist, wie
+ Webserver arbeiten und die Last verteilen, k�nnte missverstehen,
+ wof�r persistente Verbindungen gedacht sind. Im Besonderen bieten
+ sie <emphasis>keine</emphasis> M�glichkeit, 'Benutzersitzungen'
+ �ber die gleiche SQL-Verbindung zu �ffnen und
+ <emphasis>keine</emphasis> M�glichkeit, eine Transaktion effizient
+ aufzubauen, und sie k�nnen auch viele andere Dinge nicht. Um
+ absolute Klarheit zu schaffen: Persistente Verbindungen bieten
+ <emphasis>keine</emphasis> Funktionalit�t, die nicht auch von
+ nicht-persistenten Verbindungen bereitgestellt wird.
+ </simpara>
<simpara>
- Warum?</simpara>
-
+ Warum?
+ </simpara>
<simpara>
Das hat mit der Arbeitsweise von Webservern zu tun. Es gibt drei
M�glichkeiten, wie ein Webserver PHP zur Generierung von
- Webseiten einsetzen kann.</simpara>
-
+ Webseiten einsetzen kann.
+ </simpara>
<simpara>
Die erste Methode ist, PHP als CGI-'Wrapper' zu benutzen.
Wenn diese Methode eingesetzt wird, wird f�r jede Anfrage
nach einer PHP-Seite vom Webserver eine Instanz des PHP-
- Interpreters gestartet und anschliessend wieder beendet.
+ Interpreters gestartet und anschlie�end wieder beendet.
Durch die Beendigung des Interpreters nach abgeschlossener
Anfrage werden alle Ressourcen, auf die zugegriffen wurde
(wie beispielsweise eine Verbindung zu einem SQL-
- Datenbankserver) wieder geschlossen. In diesem
- Fall erreicht man nichts, wenn man persistente Verbindungen
- benutzt - sie sind eben nicht best�ndig.</simpara>
-
- <simpara>
- Die zweite und popul�rere Methode ist der Einsatz von PHP als
- Modul in einem Multiprozess-Webserver, was momentan nur
- auf den Apache zutrifft. Typischerweise hat ein Multiprozess-
- Webserver einen Prozess (den 'Eltern' Prozess), der einen Satz
- weiterer Prozesse (die 'Kinder') koordiniert, die die eigentliche Arbeit
- des Bereitstellens der Seiten �benehmen. Jede Anfrage, die von
- einen Client erfolgt, wird an einen untergeordneten Prozess, der
+ Datenbankserver) wieder geschlossen. In diesem Fall erreicht
+ man nichts, wenn man persistente Verbindungen benutzt - sie
+ sind eben nicht best�ndig.
+ </simpara>
+ <simpara>
+ Die zweite und popul�rste Methode ist der Einsatz von PHP als
+ Modul in einem Multiprozess-Webserver, was momentan nur auf den
+ Apache zutrifft. Typischerweise hat ein Multiprozess-Webserver
+ einen Prozess (den 'Eltern' Prozess), der einen Satz weiterer
+ Prozesse (die 'Kinder') koordiniert, welche die eigentliche Arbeit
+ des Bereitstellens der Seiten �bernehmen. Jede Anfrage, die von
+ einem Client erfolgt, wird an einen untergeordneten Prozess, der
noch keine andere Anfrage bearbeitet, weitergereicht. Das bedeutet,
- dass eine zweite Anfrage des Clients an den Server unter
+ dass eine zweite Anfrage des gleichen Clients an den Server unter
Umst�nden von einem anderen untergeordneten Prozess als die
erste Anfrage bearbeitet wird. In diesem Fall sorgt eine persistente
Verbindung daf�r, dass jeder untergeordnete Prozess sich nur
einmal mit dem SQL-Server verbinden muss, wenn eine solche
ben�tigt wird. Ben�tigt dann eine weitere Seite die Verbindung mit
dem SQL-Server, kann auf die zur�ckgegriffen werden,
- die der untergeordnete Prozess vorher hergestellt hat.</simpara>
-
+ die der untergeordnete Prozess vorher hergestellt hat.
+ </simpara>
<simpara>
Die letzte Methode ist, PHP als Plug-in f�r einen Multithread-
- Webserver zu benutzen. Momentan ist dies noch Theorie - PHP
- arbeitet noch nicht als Plug-in f�r irgedeinen dieser Server. An
- der Unterst�tzung f�r ISAPI, WSAPI und NSAPI wird gearbeitet,
- so dass die Nutzung von PHP mit Multithread-Serven wie
- Netscape Fast Track, Microsoft Internet Information Server (IIS)
- und O'Reilly's WebSite Pro m�glich wird. Wenn es soweit ist,
- wird das Verhalten im wesentlichen dem oben
- beschriebenen Multiprozess-Modell entsprechen.</simpara>
-
+ Webserver zu benutzen. Derzeit bietet PHP 4 Unterst�tzung f�r
+ ISAPI, WSAPI und NSAPI (unter Windows), wodurch die Nutzung von
+ PHP mit Multithread-Serven wie Netscape Fast Track (iPlanet),
+ Microsoft Internet Information Server (IIS) und O'Reilly's WebSite
+ Pro erm�glicht wird. Das Verhalten entspricht im wesentlichen dem
+ oben beschriebenen Multiprozess-Modell. Beachten Sie, dass PHP 3
+ keine Unterst�tzung f�r SAPI bietet.
+ </simpara>
<simpara>
Wozu dienen persistente Verbindungen, wenn sie keine
- zus�tzliche Funktionalit�t bieten?</simpara>
-
+ zus�tzliche Funktionalit�t bieten?
+ </simpara>
<simpara>
- Die Antwort ist ausserordentlich einfach: Effizienz. Persistente
- Verbindungen sind n�tzlich, wenn die Notwendigkeit, eine
- Verbindung zu einem SQL-Server herzustellen, hoch ist.
- Ob dies der Fall ist oder nicht, h�ngt von vielen Faktoren ab -
- zum Beispiel, um was f�r eine Datenbank es sich handelt, ob
- sie auf dem gleichen Rechner wie der Webserver l�uft oder
- welche Last die SQL-Maschine zu bew�ltigen hat usw.
- Grunds�tzlich gilt, dass, wenn viele Verbindungen hergestellt
- werden m�ssen, persistente Verbindungen ausserordentlich
- hilfreich sind. Sie veranlassen den untergeordneten Prozess,
- sich w�hrend seiner gesamten Lebensdauer lediglich einmal mit
- dem SQL-Server zu verbinden, anstatt jedesmal beim Aufruf
- einer Seite, die eine Verbindung ben�tigt. Das heisst, dass
- jeder untergeordneten Prozess, der eine persistente
- Verbindung �ffnet, eine eigene dauerhafte Verbindung zum
- Server hat. Bei 20 untergeordnete Prozessen, die ein Skript
+ Die Antwort ist au�erordentlich einfach: Effizienz. Persistente
+ Verbindungen sind n�tzlich, wenn der Aufwand f�r das Herstellen
+ einer Verbindung zu einem SQL-Server hoch ist. Ob dies der Fall ist
+ oder nicht, h�ngt von vielen Faktoren ab - zum Beispiel, um welche
+ Datenbank es sich handelt, ob sie auf dem gleichen Rechner wie der
+ Webserver l�uft oder welche Last die SQL-Maschine zu bew�ltigen hat
+ usw. Grunds�tzlich gilt, dass, wenn viele Verbindungen hergestellt
+ werden m�ssen, persistente Verbindungen au�erordentlich hilfreich
+ sind. Sie veranlassen den untergeordneten Prozess, sich w�hrend
+ seiner gesamten Lebensdauer lediglich einmal mit dem SQL-Server zu
+ verbinden, anstatt bei jedem Aufruf einer Seite, die eine Verbindung
+ ben�tigt. Das hei�t, dass jeder untergeordnete Prozess, der eine
+ persistente Verbindung �ffnet, seine eigene dauerhafte Verbindung
+ zum Server hat. Bei 20 untergeordneten Prozessen, die ein Skript
ausf�hren, das eine persistente Verbindung zum SQL-Server
herstellt, hat man beispielsweise 20 verschiedene Verbindungen
- zum SQL-Server - eine f�r jeden untergeordneten Prozess.</simpara>
-
+ zum SQL-Server - eine f�r jeden untergeordneten Prozess.
+ </simpara>
+ <simpara>
+ Beachten Sie jedoch, dass dies auch ein paar Nachteile haben kann,
+ wenn Sie eine Datenbank mit limitierten Verbindungen benutzen, welche
+ durch persistente Verbindungen �berschritten werden. Wenn Ihre Datenbank
+ ein Limit von 16 gleichzeitigen Verbindungen hat, und aufgrund einer
+ stark ausgelasteten Server-Session 17 Kind-Prozesse versuchen, eine
+ Verbindung herzustellen, wird es einem nicht gelingen. Sollten in
+ Ihren Skripten Fehler bestehen, welche das Schlie�en der Verbindungen
+ nicht erlauben (wie z.B. Endlosschleifen), kann das eine Datenbank
+ mit mit nur 32 Verbindungen sehr schnell �berschwemmen. Konsultieren
+ Sie die Dokumentation Ihrer Datenbank bez�glich der Behandlung von
+ aufgegebenen Verbindungen oder Verbindungen im Leerlauf.
+ </simpara>
+ <warning>
+ <simpara>
+ Sie sollten sich zur Vorsicht noch ein paar Gedanken machen, wenn
+ Sie persistente Verbindungen benutzen. Einer ist, wenn Sie �ber eine
+ persistente Verbindung Tabellen sperren und das Skript diese Sperre
+ aus welchem Grund auch immer nicht mehr aufheben kann, nachfolgende
+ Skripte, welche die selbe Verbindung benutzen, blockieren und den
+ Neustart von entweder dem Webserver oder dem Datenbankserver
+ verlangen. Ein weiterer ist, dass wenn Sie Transaktionen benutzen,
+ ein Transaktionsblock zu dem n�chsten die Verbindung nutzenden Skript
+ �bertragen wird, wenn die Ausf�hrung des Skriptes vor dem
+ Transaktionsblock gestoppt wird. In jedem Fall k�nnen Sie
+ <function>register_shutdown_function</function> benutzen, um eine
+ einfache Funktion zu registrieren, welche Ihre Tabellen wieder
+ entsperrt, oder Ihre Transaktionen zur�ckstellt. Besser ist es, wenn
+ Sie dieses Problem g�nzlich vermeiden, indem keine persistenten
+ Verbindungen in Skripten benutzen, welche Tabellen sperren oder
+ Transaktionen verwenden (Sie k�nnen sie immer noch anderswo benutzen).
+ </simpara>
+ </warning>
<simpara>
Eine wichtige Zusammenfassung. Persistente Verbindungen wurden
entwickelt, um eins-zu-eins Abbildungen auf regul�re Verbindungen
- zu haben. Das heisst, dass man <emphasis>immer</emphasis> in der
- Lage sein sollte, die persistenten Verbindungen durch nicht-persistente
+ zu haben. Das hei�t, dass man <emphasis>immer</emphasis> in der Lage
+ sein sollte, die persistenten Verbindungen durch nicht-persistente
zu ersetzten, ohne dass dies den Skriptablauf ver�ndert. Es <emphasis>
kann</emphasis> (und wird vermutlich auch) die Effizienz des Skriptes
- beeinflussen, aber nicht dessen Verhalten.</simpara>
-
+ beeinflussen, aber nicht dessen Verhalten.
+ </simpara>
+ <para>
+ Siehe auch <function>fbsql_pconnect</function>,
+ <function>ibase_pconnect</function>, <function>ifx_pconnect</function>,
+ <function>imap_popen</function>, <function>ingres_pconnect</function>,
+ <function>msql_pconnect</function>, <function>mssql_pconnect</function>,
+ <function>mysql_pconnect</function>, <function>OCIPLogon</function>,
+ <function>odbc_pconnect</function>, <function>Ora_pLogon</function>,
+ <function>pfsockopen</function>, <function>pg_pconnect</function> und
+ <function>sybase_pconnect</function>.
+ </para>
</chapter>
<!-- Keep this comment at the end of the file
