Persistente
connecties
zijn
connecties
naar
SQL
servers
die
niet
gesloten
worden
zogauw
je
script
beƫindigd
word
.
Zogauw
een
persistente
connectie
wordt
aangevraagd
kijkt
PHP
of
er
al
een
identieke
connectie
is
(
dat
open
gebleven
is
nadat
hij
eerder
geopend
is
)
en
als
deze
bestaat
word
die
connectie
gebruikt
.
Bestaat
er
nog
geen
vrij
identieke
connectie
dan
wordt
er
een
nieuwe
connectie
gelegd
.
Een
'
identieke
'
connectie
is
een
connectie
die
geopend
was
naar
de
zelfde
host
,
met
de
zelfde
username
en
password
(waar
van
toepassing
)
.
Diegene
die
niet
erg
vertrouwd
zijn
met
de
manier
waarop
webservers
werken
en
de
manier
waarop
ze
de
aanvragen
verdelen
kunnen
persistente
connecties
aanzien
voor
iets
dat
ze
niet
zijn
.
Persistente
geven
je
niet
de
mogelijkheid
om
"
user
session
"
op
deze
zelfde
SQL
connectie
te
hebben
,
ze
geven
je
niet
de
mogelijkheid
om
een
Transaction
efficienter
op
te
bouwen
en
ze
doen
vanalles
en
nog
wat
niet
.
Om
heel
duidelijk
te
zijn
,
ze
geven
geen
extra
functionaliteit
tegenover
wat
mogelijk
is
met
hun
niet-persistente
broertjes
.
Waarom
?
Dit
heeft
te
maken
met
de
manier
waarop
web
servers
werken
.
Er
zijn
3
manieren
waarop
je
web
server
PHP
kunt
gebruiken
om
pagina
'
s
te
genereren
.
De
eerste
manier
is
om
PHP
te
gebruiken
als
een
CGI
"
wrapper
"
.
Als
je
PHP
op
deze
manier
gebruikt
word
een
instantie
van
de
PHP
interpreter
aangemaakt
en
vernietigd
voor
iedere
PHP
pagina
die
wordt
opgevraagd
.
Omdat
het
na
iedere
aanvraag
vernietigd
word
,
worden
middelen
die
PHP
gebruikt
heeft
(
zoals
een
connectie
naar
een
database
server
)
vrijgegeven
(gesloten
)
.
In
dit
geval
heeft
het
geen
zin
om
persistente
connecties
te
gebruiken
-
-
ze
blijven
simpelweg
niet
bestaan
.
De
tweede
,
en
meest
populaire
,
manier
is
PHP
te
gebruiken
als
een
module
in
een
multiprocess
web
server
,
op
dit
moment
alleen
Apache
.
Een
multiprocess
webserver
heeft
standaard
1
process
(
de
parent
)
welke
een
partij
andere
process
(child
processen
)
coordineert
.
Deze
child
processen
nemen
zorg
voor
het
verwerken
van
aanvragen
.
Als
een
aanvraag
binnenkomt
word
deze
doorgegeven
aan
een
child
process
dat
op
dat
moment
niets
te
doen
heeft
.
Dat
betekent
dat
als
dezelfde
gebruiker
een
nieuwe
aanvraag
stuurt
deze
door
een
ander
child
process
afgehandeld
kan
worden
.
Wat
een
persistente
connectie
voor
je
doet
in
deze
context
is
dat
een
child
process
slechts
een
connectie
maakt
naar
een
SQL
server
bij
het
eerste
script
dat
zo
'
n
connectie
vereist
.
Als
een
andere
pagina
daarna
ook
een
dergelijke
connectie
nodig
heeft
dan
kan
de
connectie
die
al
eerder
gelegd
was
opnieuw
gebruikt
worden
.
De
laatste
methode
is
om
PHP
te
gebruiken
als
een
plug-in
in
een
multithreaded
web
server
.
Op
dit
moment
is
dit
slechts
theoretisch
-
-
PHP
werkt
nog
niet
als
een
plugin
voor
een
multithreaded
web
server
.
Er
wordt
vooruitgang
geboekt
op
de
ontwikkeling
voor
support
voor
ISAPI
,
WSAPI
en
NSAPI
(
onder
Windows
)
welke
allemaal
mogelijk
maken
dat
PHP
gebruikt
wordt
als
een
plug-in
op
multithreaded
servers
zoals
Netscape
FastTrack
,
Microsofts
Internet
Information
Server
(IIS
)
en
O'Reilly
's
WebSite
Pro
.
Zogauw
dit
compleet
is
zal
het
gedrag
van
PHP
in
deze
context
overeen
komen
met
het
gedrag
van
PHP
in
een
multiprocess
model
,
wat
hierboven
beschreven
is
.
Als
persistente
connecties
geen
extra
functionaliteit
geven
,
waar
zijn
ze
dan
goed
voor
?
Het
antwoord
is
erg
simpel
-
-
betere
performance
.
Persistente
connecties
zijn
goed
als
de
overhead
om
een
connectie
naar
je
SQL
server
te
leggen
groot
is
.
Of
die
overhead
daadwerkelijk
groot
is
hangt
af
van
veel
factoren
.
Zoals
,
wat
voor
database
is
het
,
draait
de
server
op
de
zelfde
machine
als
de
webserver
.
Hoe
druk
de
server
met
de
database
het
heeft
.
Uiteindelijk
als
deze
overhead
inderdaad
groot
is
,
zijn
persistente
connecties
een
goede
hulp
.
Ze
zorgen
ervoor
dat
het
child
process
zolang
het
process
leeft
slechts
1x
een
connectie
naar
de
SQL
server
legt
,
in
plaats
van
iedere
keer
dat
het
child
process
een
connectie
legt
zogauw
het
een
script
verwerkt
dat
zo
'
n
connectie
vereist
.
Dit
betekent
dat
ieder
child
process
z
'
n
eigen
connectie
heeft
naar
de
SQL
server
.
Bijvoorbeeld
,
als
je
20
verschillende
child
processen
hebt
dat
een
script
verwerkt
dat
een
persistente
connectie
legt
,
dan
zou
je
20
verschillende
connecties
hebben
naar
de
SQL
server
.
Een
van
elk
childprocess
.
Onthoudt
wel
dat
dit
z
'
n
nadelen
kan
hebben
als
je
een
database
server
gebruikt
met
een
limiet
op
het
aantal
connecties
.
Als
je
database
een
limiet
van
16
gelijke
connecties
heeft
,
en
in
laten
we
zeggen
dat
we
een
drukke
server
hebben
,
17
child
processes
proberen
een
connectie
te
leggen
,
zal
er
een
hierin
falen
.
Als
je
scripts
bugs
hebben
welke
niet
de
connectie
sluiten
kan
een
database
met
slechts
32
connecties
snel
"
verdrinken
"
.
Zoek
door
de
database
documentatie
naar
informatie
over
het
sluiten
van
verlaten
of
niet-gebruikte
connecties
.
Een
belangrijke
samenvatting
.
Persistente
connectie
zijn
ontwikkeld
om
in
principe
het
zelfde
te
werken
als
standaard
connecties
.
Dat
betekent
dat
je
altijd
de
mogelijk
hebt
om
persistente
connecties
te
vervangen
met
niet-persistente
connecties
,
zonder
dat
het
gedrag
van
je
script
wijzigt
.
Het
kan
(
en
zal
waarschijnlijk
)
de
effectiviteit
van
je
script
verbeteren
,
maar
het
zal
nooit
het
gedrag
veranderen
.