Connexions persistantes aux bases de donn�es

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 ; elles 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. �tant donn� que cet interpr�teur 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, 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 multithread. Actuellement, PHP 4 supporte ISAPI, WSAPI, et NSAPI (sous Windows), qui permettent tous d'utiliser PHP comme un module sur un serveur multithread tel que Netscape FastTrack (iPlanet), Microsoft 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.

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.

Avertissement

Il y a quelques autres limitations � bien garder en t�te lorsque vous utilisez les connexions persistantes. L'une est que lorsque vous posez un verrou avec une connexion persistante, si le script ne peut lib�rer le verrou pour une raison quelconque, alors les autres scripts qui r�utiliseront la connexion seront bloqu�s ind�finiment, et vous imposeront le red�marrage du serveur ou de la base de donn�es. Une autre limitation est, lors de l'utilisation des transactions, un bloc de transaction non ferm� sera prolong� au script suivant, s'il n'est pas ferm� par le script initiateur. Dans les deux cas, vous pouvez utiliser la fonction register_shutdown_function() pour enregistrer une fonction simple de nettoyage, pour d�verrouiller les tables, et annuler les transactions en cours. Mieux encore, �vitez le probl�me enti�rement en n'utilisant pas les connexions persistantes dans les scripts qui ont besoin de verrous ou de transactions. Vous pourrez toujours les utiliser ailleurs.

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�.

Voir aussi fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(), ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(), ociplogon(), odbc_pconnect(), oci_pconnect(), pfsockopen(), pg_pconnect() et sybase_pconnect().