persistent-connections.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- EN-Revision: 0799f7789c50a11b746ad713cc8787e4b04dd926 Maintainer: hholzgra Status: ready -->
<!-- Credits: tom -->
 <chapter xml:id="features.persistent-connections" xmlns="http://docbook.org/ns/docbook">
  <title>Persistente Datenbankverbindungen</title>

  <simpara>
   Persistente Verbindungen sind Verbindungen, die nach
   Abarbeitung des Skriptes nicht geschlossen werden. Wenn eine
   persistente Verbindung angefordert wird, prüft PHP zuerst, ob
   bereits eine identische persistente Verbindung (die vielleicht
   vorher offen geblieben ist) existiert und benutzt sie in diesem Fall.
   Sollte keine Verbindung existieren, wird eine hergestellt. Eine
   '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 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 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> 
  <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>
  <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 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ä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 gleichen Clients an den Server unter
   Umständen von einem anderen untergeordneten Prozess als die
   erste Anfrage bearbeitet wird. Wurde eine persistente Verbindung
   einmal geöffnet kann jede danach folgende Seite innerhalb des
   gleichen Prozesses diese bereits zum Server bestehende Verbindung
   weiter verwenden.
  </simpara>
  <simpara>
   Die letzte Methode ist, PHP als Plug-in für einen Multithread-
   Webserver zu benutzen. Derzeit bietet PHP Unterstützung für
   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.
  </simpara>
  <simpara>
   Wozu dienen persistente Verbindungen, wenn sie keine 
   zusätzliche Funktionalität bieten?
  </simpara>
  <simpara>
   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>
  <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 16 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 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>
  <para>
   Siehe auch <function>ibase_pconnect</function>, <function>ociplogon</function>,
   <function>odbc_pconnect</function>, <function>oci_pconnect</function>,
   <function>pfsockopen</function> und <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:
-->