mirror of
https://github.com/php/doc-fr.git
synced 2026-03-23 22:52:18 +01:00
3823a2f469
i.e. → c.-à-d., e.g. → p. ex., accents sur majuscules (À, É, Ç), ligatures (cœur, sœur, nœud, œuvre, manœuvres), accords genre/nombre, conjugaisons, typos (verrouillage, milliseconde, aléatoire), etc.
235 lines
11 KiB
XML
235 lines
11 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!-- EN-Revision: cd8b964b8566801265f0d287db6eb651f93be950 Maintainer: lacatoire Status: ready -->
|
|
<!-- Reviewed: yes -->
|
|
|
|
<chapter xml:id="features.persistent-connections" xmlns="http://docbook.org/ns/docbook">
|
|
<title>Connexions persistantes aux bases de données</title>
|
|
|
|
<simplesect>
|
|
<title>Qu'est-ce que les connexions persistantes ?</title>
|
|
<simpara>
|
|
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).
|
|
</simpara>
|
|
<simpara>
|
|
Il n'y a pas de méthode pour demander une connexion spécifique, ou garantir
|
|
que l'on obtient une connexion existante ou une toute nouvelle (si toutes les
|
|
connexions sont utilisées, ou si la requête est servie par un autre processus,
|
|
qui a un ensemble de connexions séparé).
|
|
</simpara>
|
|
<simpara>
|
|
Cela signifie qu'il n'est pas possible d'utiliser les connexions persistantes PHP pour, par exemple :
|
|
</simpara>
|
|
<simplelist>
|
|
<member>assigner une session de base de données spécifique à un utilisateur web spécifique</member>
|
|
<member>créer une grande transaction à travers plusieurs requêtes</member>
|
|
<member>initier une requête sur une demande et collecter les résultats sur une autre</member>
|
|
</simplelist>
|
|
<simpara>
|
|
Les connexions persistantes ne donnent <emphasis>aucune</emphasis>
|
|
fonctionnalité qui n'était pas possible avec des connexions non persistantes.
|
|
</simpara>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="persistent-connections.web">
|
|
<title>Requêtes Web</title>
|
|
<simpara>
|
|
Il existe deux façons pour le serveur web d'utiliser PHP pour générer
|
|
des pages web :
|
|
</simpara>
|
|
<simpara>
|
|
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. Dans ce cas, il n'y a
|
|
rien à gagner à utiliser des connexions persistantes - elles ne persistent tout simplement pas.
|
|
</simpara>
|
|
<simpara>
|
|
La deuxième méthode, de loin la plus prisée, est d'exécuter PHP-FPM, ou PHP sous la forme d'un
|
|
module sur un serveur multiprocessus, ce qui revient à dire : Apache.
|
|
Ces configurations ont généralement un processus (le 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 permettent alors de ne se 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.
|
|
</simpara>
|
|
<note>
|
|
<para>
|
|
Il est possible de vérifier quelle méthode les requêtes web utilisent en vérifiant la valeur de
|
|
"Server API" dans la sortie de <function>phpinfo</function> ou la valeur de
|
|
<constant>PHP_SAPI</constant>, exécutée depuis une requête web.
|
|
</para>
|
|
<para>
|
|
Si la valeur de Server API est "Apache 2 Handler" ou "FPM/FastCGI", alors les
|
|
connexions persistantes seront utilisées entre les requêtes servies par le même
|
|
worker. Pour toute autre valeur, les connexions persistantes ne persisteront pas
|
|
après chaque requête.
|
|
</para>
|
|
</note>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="persistent-connections.cli">
|
|
<title>Processus en ligne de commande</title>
|
|
<simpara>
|
|
Comme PHP en ligne de commande utilise un nouveau processus pour chaque script,
|
|
les connexions persistantes ne sont pas partagées entre les scripts en ligne de commande, donc il n'y a aucun
|
|
intérêt à les utiliser dans des scripts transitoires tels que les crons ou les commandes.
|
|
Cependant, elles peuvent être utiles si, par exemple, l'on écrit un serveur d'applications
|
|
de longue durée qui sert de nombreuses requêtes ou tâches et que chacune peut
|
|
avoir besoin de sa propre connexion à la base de données.
|
|
</simpara>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="persistent-connections.why">
|
|
<title>Pourquoi les utiliser ?</title>
|
|
<simpara>
|
|
Les connexions persistantes sont utiles si le coût de création d'une liaison
|
|
vers le serveur SQL est élevé. Que ce coût soit réellement élevé ou pas ceci 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. Avec 20
|
|
processus fils, il suffit d'avoir 20 connexions persistantes ouvertes,
|
|
une par fils.
|
|
</simpara>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="persistent-connections.drawbacks.conn-limits">
|
|
<title>Inconvénients potentiels : limites de connexion</title>
|
|
<simpara>
|
|
Il est à noter que les connexions persistantes ont quelques inconvénients
|
|
lors de l'hébergement d'une base de données dont le nombre maximal de
|
|
connexion risque d'être atteint par les connexions persistantes.
|
|
Si la base de données a une limite de 16 connexions simultanées,
|
|
et que lors d'une session serveur chargée, 17 processus fils tentent de
|
|
se connecter, l'un d'entre eux ne pourra pas. S'il y a des bogues dans
|
|
les scripts qui empêchent les connexions de se fermer (comme des boucles
|
|
infinies), la base de données avec seulement 16 connexions peut être
|
|
rapidement submergée.
|
|
</simpara>
|
|
<simpara>
|
|
Les connexions persistantes augmenteront généralement le nombre de connexions ouvertes
|
|
à un moment donné parce que les travailleurs inactifs conserveront les connexions pour
|
|
les requêtes précédentes qu'ils ont servies. Si un grand nombre de travailleurs est lancé pour
|
|
gérer un afflux de requêtes, les connexions qu'ils ont ouvertes resteront jusqu'à
|
|
ce que le travailleur soit tué ou que le serveur de base de données ferme la connexion.
|
|
</simpara>
|
|
<simpara>
|
|
Il faut s'assurer que le nombre maximal de connexions autorisées par le serveur de base de données
|
|
est supérieur au nombre maximal de travailleurs de requêtes web (plus toute autre
|
|
utilisation telle que les crons ou les connexions administratives).
|
|
</simpara>
|
|
<simpara>
|
|
Vérifier la documentation de la base de données pour des informations sur la gestion des connexions abandonnées ou
|
|
inactives (timeouts). Des timeouts longs peuvent augmenter considérablement le
|
|
nombre de connexions persistantes ouvertes à un moment donné.
|
|
</simpara>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="persistent-connections.drawbacks.state">
|
|
<title>Inconvénients potentiels : Maintien de l'état de connexion</title>
|
|
<simpara>
|
|
Certaines extensions de base de données effectuent un nettoyage automatique lorsque la connexion est
|
|
réutilisée ; d'autres laissent cette tâche à la discrétion du développeur d'application.
|
|
En fonction de l'extension de base de données choisie et de la conception de l'application, un
|
|
nettoyage manuel peut être nécessaire avant la fin du script. Les modifications qui peuvent laisser
|
|
les connexions dans un état inattendu incluent :
|
|
</simpara>
|
|
<simplelist>
|
|
<member>Base de données sélectionnée / par défaut</member>
|
|
<member>Verrous de table</member>
|
|
<member>Transactions non commises</member>
|
|
<member>Tables temporaires</member>
|
|
<member>Paramètres ou fonctionnalités spécifiques à la connexion telles que le profilage</member>
|
|
</simplelist>
|
|
<simpara>
|
|
Les verrous de table et les transactions qui ne sont pas nettoyés ou fermés peuvent
|
|
entraîner le blocage indéfini d'autres requêtes et/ou provoquer
|
|
des modifications inattendues lors de la réutilisation ultérieure de la connexion.
|
|
</simpara>
|
|
<simpara>
|
|
Avoir la mauvaise base de données sélectionnée entraînera la réutilisation de
|
|
la connexion incapable d'exécuter les requêtes suivantes comme prévu (ou de les exécuter sur
|
|
la mauvaise base de données si les schémas sont suffisamment similaires).
|
|
</simpara>
|
|
<simpara>
|
|
Si les tables temporaires ne sont pas nettoyées, les requêtes suivantes ne pourront pas
|
|
recréer la même table.
|
|
</simpara>
|
|
<simpara>
|
|
Il est possible d'implémenter le nettoyage en utilisant des destructeurs de classe ou
|
|
<function>register_shutdown_function</function>. Il est également possible d'envisager
|
|
des proxies de mise en pool de connexions dédiés qui incluent cela dans
|
|
leur fonctionnalité.
|
|
</simpara>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="persistent-connections.final-words">
|
|
<title>Derniers mots</title>
|
|
<simpara>
|
|
Étant donné leur comportement et les inconvénients potentiels décrits ci-dessus, il est recommandé de ne pas
|
|
utiliser les connexions persistantes sans une réflexion approfondie. Elles ne devraient pas être
|
|
utilisées sans mettre en œuvre des modifications supplémentaires dans l'application et une configuration
|
|
soigneuse du serveur de base de données et du serveur web et/ou PHP-FPM.
|
|
</simpara>
|
|
<simpara>
|
|
Considérez des solutions alternatives telles que l'investigation et la correction des causes des
|
|
surcoûts de création de connexion (par exemple, la désactivation des recherches DNS inverses sur
|
|
le serveur de base de données), ou des proxies de mise en pool de connexions dédiés.
|
|
</simpara>
|
|
<simpara>
|
|
Pour les API web à fort volume, envisagez d'utiliser des runtimes alternatifs ou des serveurs
|
|
d'applications de longue durée.
|
|
</simpara>
|
|
</simplesect>
|
|
|
|
<simplesect role="seealso" xml:id="persistent-connections.seealso">
|
|
&reftitle.seealso;
|
|
<simplelist>
|
|
<member><function>ibase_pconnect</function></member>
|
|
<member><function>oci_pconnect</function></member>
|
|
<member><function>odbc_pconnect</function></member>
|
|
<member><function>pfsockopen</function></member>
|
|
<member><function>pg_connect</function></member>
|
|
<member><link linkend="mysqli.persistconns">MySQLi et les connexions persistantes</link></member>
|
|
<member><link linkend="pdo.connections">Gestion de connexions PDO</link></member>
|
|
</simplelist>
|
|
</simplesect>
|
|
</chapter>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode: sgml
|
|
sgml-omittag:t
|
|
sgml-shorttag:t
|
|
sgml-minimize-attributes:nil
|
|
sgml-always-quote-attributes:t
|
|
sgml-indent-step:1
|
|
sgml-indent-data:t
|
|
indent-tabs-mode:nil
|
|
sgml-parent-document:nil
|
|
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
|
|
sgml-exposed-tags:nil
|
|
sgml-local-catalogs:nil
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
-->
|