-
Notifications
You must be signed in to change notification settings - Fork 0
/
features.persistent-connections.html
257 lines (257 loc) · 7.2 KB
/
features.persistent-connections.html
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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
<HTML
><HEAD
><TITLE
>Persistent Database Connections</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
REL="HOME"
TITLE="PHP Manual"
HREF="manual.html"><LINK
REL="UP"
TITLE="Features"
HREF="features.html"><LINK
REL="PREVIOUS"
TITLE="Connection handling"
HREF="features.connection-handling.html"><LINK
REL="NEXT"
TITLE="Function Reference"
HREF="funcref.html"><META
NAME="HTTP_EQUIV"
CONTENT="text/html; charset=ISO-8859-1"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PHP Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="features.connection-handling.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="funcref.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="features.persistent-connections"
>Chapter 22. Persistent Database Connections</A
></H1
><P
> Persistent connections are SQL links that do not close when the
execution of your script ends. When a persistent connection is
requested, PHP checks if there's already an identical persistent
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).
</P
><P
> People who aren't thoroughly familiar with the way web servers work
and distribute the load may mistake persistent connects for what
they're not. In particular, they do <I
CLASS="emphasis"
>not</I
> give
you an ability to open 'user sessions' on the same SQL link, they
do <I
CLASS="emphasis"
>not</I
> 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 <I
CLASS="emphasis"
>any</I
>
functionality that wasn't possible with their non-persistent
brothers.
</P
><P
> Why?
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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
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.
</P
><P
> If persistent connections don't have any added functionality, what
are they good for?
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> An important summary. Persistent connections were designed to have
one-to-one mapping to regular connections. That means that you
should <I
CLASS="emphasis"
>always</I
> be able to replace persistent
connections with non-persistent connections, and it won't change
the way your script behaves. It <I
CLASS="emphasis"
>may</I
> (and
probably will) change the efficiency of the script, but not its
behavior!
</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="features.connection-handling.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="manual.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="funcref.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Connection handling</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="features.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Function Reference</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>