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.