Persistente
Verbindungen
sind
SQL-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
.
Anmerkung
:
Auch
andere
Erweiterungen
bieten
persistente
Verbindungen
,
wie
z.B
.
IMAP
extension
.
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
keine
Möglichkeit
,
'
Benutzersitzungen
'
über
die
gleiche
SQL-Verbindung
zu
öffnen
und
keine
Möglichkeit
,
eine
Transaktion
effizient
aufzubauen
,
und
sie
können
auch
viele
andere
Dinge
nicht
.
Um
absolute
Klarheit
zu
schaffen
:
Persistente
Verbindungen
bieten
keine
Funktionalität
,
die
nicht
auch
von
nicht-persistenten
Verbindungen
bereitgestellt
wird
.
Warum
?
Das
hat
mit
der
Arbeitsweise
von
Webservern
zu
tun
.
Es
gibt
drei
Möglichkeiten
,
wie
ein
Webserver
PHP
zur
Generierung
von
Webseiten
einsetzen
kann
.
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
.
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
.
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
.
Die
letzte
Methode
ist
,
PHP
als
Plug-in
für
einen
Multithread
-
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
.
Wozu
dienen
persistente
Verbindungen
,
wenn
sie
keine
zusätzliche
Funktionalität
bieten
?
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
.
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
.
Warnung
|
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
register_shutdown_function(
)
In
jedem
Fall
können
Sie
register_shutdown_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
)
.
|
Eine
wichtige
Zusammenfassung
.
Persistente
Verbindungen
wurden
entwickelt
,
um
eins-zu-eins
Abbildungen
auf
reguläre
Verbindungen
zu
haben
.
Das
heißt
,
dass
man
immer
in
der
Lage
sein
sollte
,
die
persistenten
Verbindungen
durch
nicht-persistente
zu
ersetzten
,
ohne
dass
dies
den
Skriptablauf
verändert
.
Es
kann
(
und
wird
vermutlich
auch
)
die
Effizienz
des
Skriptes
beeinflussen
,
aber
nicht
dessen
Verhalten
.
Siehe
auch
fbsql_pconnect(
)
,
ibase_pconnect(
)
,
ifx_pconnect(
)
,
imap_popen(
)
,
ingres_pconnect(
)
,
msql_pconnect(
)
,
mssql_pconnect(
)
,
mysql_pconnect(
)
,
OCIPLogon(
)
,
odbc_pconnect(
)
,
Ora_pLogon(
)
,
pfsockopen(
)
,
pg_pconnect(
)
und
sybase_pconnect(
)
.