1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
<?xml version="1.0" encoding="iso-8859-1"?>
<chapter id="features.persistent-connections">
<title>Persistente Datenbankverbindungen</title>
<simpara>
Persistente Verbindungen sind SQL-Verbindungen, die nach
Abarbeitung des Skriptes nicht geschlossen werden. Wenn eine
persistente Verbindung angefordert wird, prft 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 durchgngig mit der Art und Weise, wie
Webserver arbeiten und die Last verteilen, vertraut ist, knnte
missverstehen, wofr persistente Verbindungen gedacht sind.
Im Besonderen bieten sie <emphasis>keine</emphasis>
Mglichkeit, 'Benutzersitzungen' auf der gleichen SQL-Verbindung
zu ffnen und <emphasis>keine</emphasis> Mglichkeit, eine
Transaktion aufzubauen, und sie knnen viele
andere Sachen nicht. Um absulute Klarheit zu schaffen:
Persistente Verbindungen bieten <emphasis>keine</emphasis>
Funktionalitt, 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
Mglichkeiten, 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 fr jede Anfrage
nach einer PHP-Seite vom Webserver eine Instanz des PHP-
Interpreters gestartet und anschliessend 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 bestndig.</simpara>
<simpara>
Die zweite und populrere 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
noch keine andere Anfrage bearbeitet, weitergereicht. Das bedeutet,
dass eine zweite Anfrage des Clients an den Server unter
Umstnden von einem anderen untergeordneten Prozess als die
erste Anfrage bearbeitet wird. In diesem Fall sorgt eine persistente
Verbindung dafr, dass jeder untergeordnete Prozess sich nur
einmal mit dem SQL-Server verbinden muss, wenn eine solche
bentigt wird. Bentigt dann eine weitere Seite die Verbindung mit
dem SQL-Server, kann auf die zurckgegriffen werden,
die der untergeordnete Prozess vorher hergestellt hat.</simpara>
<simpara>
Die letzte Methode ist, PHP als Plug-in fr einen Multithread-
Webserver zu benutzen. Momentan ist dies noch Theorie - PHP
arbeitet noch nicht als Plug-in fr irgedeinen dieser Server. An
der Untersttzung fr 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 mglich wird. Wenn es soweit ist,
wird das Verhalten im wesentlichen dem oben
beschriebenen Multiprozess-Modell entsprechen.</simpara>
<simpara>
Wozu dienen persistente Verbindungen, wenn sie keine
zustzliche Funktionalitt bieten?</simpara>
<simpara>
Die Antwort ist ausserordentlich einfach: Effizienz. Persistente
Verbindungen sind ntzlich, wenn die Notwendigkeit, eine
Verbindung zu einem SQL-Server herzustellen, hoch ist.
Ob dies der Fall ist oder nicht, hngt von vielen Faktoren ab -
zum Beispiel, um was fr eine Datenbank es sich handelt, ob
sie auf dem gleichen Rechner wie der Webserver luft oder
welche Last die SQL-Maschine zu bewltigen hat usw.
Grundstzlich gilt, dass, wenn viele Verbindungen hergestellt
werden mssen, persistente Verbindungen ausserordentlich
hilfreich sind. Sie veranlassen den untergeordneten Prozess,
sich whrend seiner gesamten Lebensdauer lediglich einmal mit
dem SQL-Server zu verbinden, anstatt jedesmal beim Aufruf
einer Seite, die eine Verbindung bentigt. 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
ausfhren, das eine persistente Verbindung zum SQL-Server
herstellt, hat man beispielsweise 20 verschiedene Verbindungen
zum SQL-Server - eine fr jeden untergeordneten Prozess.</simpara>
<simpara>
Eine wichtige Zusammenfassung. Persistente Verbindungen wurden
entwickelt, um eins-zu-eins Abbildungen auf regulre Verbindungen
zu haben. Das heisst, dass man <emphasis>immer</emphasis> in der
Lage sein sollte, die persistenten Verbindungen durch nicht-persistente
zu ersetzten, ohne dass dies den Skriptablauf verndert. Es <emphasis>
kann</emphasis> (und wird vermutlich auch) die Effizienz des Skriptes
beeinflussen, aber nicht dessen Verhalten.</simpara>
</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:"../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
|
