Hoofdstuk 21. Persistente Database connecties

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 .