Les connexions persistantes aux bases de donn�es SQL sont
des connexions qui ne se referment pas � la fin du script.
Lorsqu'une connexion persistante est demand�e, PHP s'assure
qu'il n'y a pas une autre connexion identique (qui serait ouverte
pr�c�demment, avec le m�me nom d'h�te,
d'utilisateur et le m�me mot de passe), et si une telle connexion
existe, elle est utilis�e. Sinon, elle est cr��e.
Une connexion identique est une connexion qui a ouvert le m�me
h�te, avec le m�me nom et le m�me mot de passe (s'ils
sont n�cessaires).
Ceux qui ne sont pas rompus aux techniques des serveurs web et leur
distribution de la charge de travail, se font parfois une fausse
id�e de ces connexions persistantes. En particulier,
les connexions persistantes ne permettent pas l'ouverture de plusieurs
sessions avec le m�me lien, ne permettent pas la r�alisation
de transactions efficaces et ne font pas le caf�. En fait,
pour �tre extr�mement clair sur le sujet, les
connexions persistantes ne vous donnent aucune fonctionnalit�
de plus que les connexions non persistantes.
Alors pourquoi les connexions persistantes?
Cela s'explique par la mani�re avec laquelle les serveurs web
fonctionnent. Il y a trois mani�res d'utiliser PHP pour
g�n�rer des pages.
La premi�re est d'utiliser PHP comme un CGI (Common Interface Gateway).
Lorsque PHP fonctionne de cette mani�re, une instance de
l'interpr�teur PHP est cr��e puis d�truite
pour chaque page demand�e. Etant donn� que cet interpreteur est
d�truit apr�s chaque requ�te, toutes les
ressources acquises (comme une connexion � une base SQL),
sont purement et simplement d�truites.
La deuxi�me m�thode, et de loin, la plus pris�e,
est d'ex�cuter PHP sous la forme d'un module sur un serveur
multi-processus, ce qui revient � dire : Apache. Un tel serveur
a typiquement un processus parent qui coordonne un ensemble de processus fils,
qui servent les fichiers. Lorsque les requ�tes parviennent depuis
un client, elles sont transmises � un fils disponible. Cela signifie
que si un client fait une deuxi�me requ�te, il peut
�tre servi par un processus client diff�rent du premier.
Les connexions persistantes vous permettent alors de ne vous connecter
� une base SQL que la premi�re fois. Lors des connexions
ult�rieures, les processus fils pourront r�utiliser la
connexion ouverte pr�c�demment.
La derni�re m�thode est d'utiliser PHP sous la forme d'un
module de serveur multi-threads. Actuellement, PHP 4 supporte
ISAPI, WSAPI, et NSAPI (sous Windows), qui permettent tous d'utiliser
PHP comme un module sur un serveur multi-threads tel que Netscape
FastTrack (iPlanet), Microsoft's Internet Information Server (IIS), et
O'Reilly's WebSite Pro. Le comportement est essentiellement le m�me
que pour les serveurs multi-processus d�crits pr�c�demment.
Notez que SAPI n'est pas disponible avec PHP 3.
Si les connexions persistantes n'ont aucune fonctionnalit� de plus,
� quoi servent-elles?
La r�ponse est extr�mement simple : efficacit�. Les
connexions persistantes sont un bon moyen d'acc�l�rer les
acc�s � une base SQL si le traitement de connexion �
la base est long. Ce temps d�pend de nombreux facteurs : le type
de base de donn�es, cette base est-elle sur le m�me serveur
ou pas, quelle est la charge du serveur de base de donn�es, etc...
Si le temps de connexion est long, les connexions persistantes seront
bien utiles, car une fois ouverte par un processus fils, la connexion est
r�utilisable sans avoir � se reconnecter. Si vous avez 20
processus fils, il suffit d'avoir 20 connexions persistantes ouvertes,
une par fils.
Notez que les connexions persistantes ont quelques inconv�nients
si vous h�bergez une base de donn�es, dont le nombre maximal de
connexion risque d'�tre atteint par les connexions persistantes.
Si votre base de donn�es accepte jusqu'� 16 connexions
simultan�es et que, 17 processus essaient de se connecter,
le dernier restera sur la touche. S'il y a des erreurs dans les scripts qui ne permettent
pas de fermer la connexion (par exemple, une boucle infinie), votre
serveur sera rapidement engorg�. V�rifiez la documentation de votre
base de donn�es pour savoir comment elle traite les connexions
inactives ou abandonn�es.
R�sumons-nous : les connexions persistantes ont �t�
d�finies pour avoir les m�mes fonctionnalit�s que
les connexions non persistantes. Les deux types de connexions
sont parfaitement interchangeables, et n'affecteront pas le
comportement de votre script : uniquement son efficacit�.