PHP  
downloads | documentation | faq | getting help | mailing lists | | php.net sites | links 
search for in the  
previousGestion des connexionsSafe modenext
Last updated: Tue, 09 Jul 2002
view the printer friendly version or the printer friendly version with notes or change language to English | Brazilian Portuguese | Chinese | Czech | Dutch | Finnish | German | Hungarian | Italian | Japanese | Korean | Polish | Romanian | Russian | Spanish | Swedish | Turkish

Chapitre 22. 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, 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�.

User Contributed Notes
Connexions persistantes aux bases de donn�es
add a note about notes
[email protected]
18-Apr-2000 01:28

Yes, with nonpersistent connections database connections last only while a database-related request is processed, thus reducing the load on the database server.
However, latency will be somewhat higher since a database connection must be opened before a request can be handeled.

[email protected]
15-Aug-2002 09:13

If anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why:

"You are probably using a multi-process web server such as Apache. Since
database connections cannot be shared among different processes a new
one is created if the request happen to come to a different web server
child process."

add a note about notes
previousGestion des connexionsSafe modenext
Last updated: Tue, 09 Jul 2002
show source | credits | stats | mirror sites
Copyright © 2001, 2002 The PHP Group
All rights reserved.
This mirror generously provided by:
Last updated: Thu Aug 29 20:06:18 2002 CEST