Connexions de base de données persistantes : oui ou non ?

Question

J'utilise la couche PDO de PHP pour l'accès aux données dans un projet, et je l'ai lu et j'ai constaté qu'elle offre un bon support inné pour les connexions persistantes à la base de données.Je me demande quand/si je devrais les utiliser.Vais-je voir des avantages en termes de performances dans une application lourde en CRUD ?Y a-t-il des inconvénients à prendre en compte, peut-être liés à la sécurité ?

Si cela vous intéresse, j'utilise MySQL 5.x.

Answer 1

Vous pouvez l'utiliser comme un "ensemble de règles" approximatif :

OUI, utilisez des connexions persistantes si :

• Il n'y a que quelques applications/utilisateurs accédant à la base de données, c'est-à-direvous n'obtiendrez pas 200 connexions ouvertes (mais probablement inactives), car 200 utilisateurs différents sont partagés sur le même hôte.
• La base de données s'exécute sur un autre serveur auquel vous accédez via le réseau
• Une (une) application accède très souvent à la base de données

NON, n'utilisez pas de connexions persistantes si :

• Votre application n'a besoin d'accéder à la base de données que 100 fois par heure.
• Vous disposez de plusieurs serveurs Web accédant à un serveur de base de données
• Vous utilisez Apache en mode préfork.Il utilise une connexion pour chaque processus enfant, qui peut s'accélérer assez rapidement.(via @Powerlord dans les commentaires)

L'utilisation de connexions persistantes est considérablement plus rapide, surtout si vous accédez à la base de données via un réseau.Cela ne fait pas beaucoup de différence si la base de données s'exécute sur la même machine, mais elle est quand même un peu plus rapide.Cependant - comme son nom l'indique - la connexion est persistante, c'est-à-direil reste ouvert, même s'il n'est pas utilisé.

Le problème est que dans la "configuration par défaut", MySQL n'autorise que 1000 "canaux ouverts" parallèles.Après cela, les nouvelles connexions sont refusées (vous pouvez modifier ce paramètre).Donc, si vous avez - disons - 20 serveurs Web avec chacun 100 clients, et que chacun d'entre eux n'a qu'un accès à une page par heure, un simple calcul vous montrera que vous aurez besoin de 2 000 connexions parallèles à la base de données.Cela ne marchera pas.

Donc :Utilisez-le uniquement pour les applications comportant de nombreuses demandes.

Answer 2

En bref, mon expérience montre que les connexions persistantes doivent être évitées autant que possible.

Notez que mysql_close est une opération sans opération (no-op) pour les connexions créées à l'aide de mysql_pconnect.Cela signifie que la connexion persistante ne peut pas être fermée à volonté par le client.Une telle connexion sera fermée par le serveur mysqldb lorsqu'aucune activité ne se produit sur la connexion pendant une durée supérieure à attente_timeout.Si attente_timeout est une grande valeur (disons 30 minutes), alors le serveur de base de données mysql peut facilement atteindre max_connections limite.Dans ce cas, mysql db n'acceptera aucune demande de connexion future. C'est à ce moment-là que votre téléavertisseur commence à émettre un bip.

Afin d'éviter d'atteindre max_connections limite, l'utilisation d'une connexion persistante nécessite un équilibrage minutieux des variables suivantes...

1. Nombre de processus Apache sur un hôte
2. Nombre total d'hôtes exécutant Apache
3. variable wait_timout dans le serveur de base de données mysql
4. variable max_connections dans le serveur de base de données mysql
5. Nombre de requêtes traitées par un processus Apache avant sa réapparition

Alors, utilisez une connexion persistante après suffisamment de délibération.Vous ne souhaiterez peut-être pas inviter des problèmes d'exécution complexes pour un petit gain que vous obtenez d'une connexion persistante.

Answer 3

Créer des connexions à la base de données est une opération assez coûteuse.Les connexions persistantes sont une bonne idée.Dans le monde ASP.Net et Java, nous avons un « pooling de connexions », ce qui est à peu près la même chose, et c'est aussi une bonne idée.

Answer 4

OMI, la vraie réponse à cette question est celle qui fonctionne le mieux pour votre application.Je vous recommande de comparer votre application en utilisant des connexions persistantes et non persistantes.

Maggie Nelson @ Orienté objectivement posté à ce sujet en août et Robert Swarthout a fait un post d'accompagnement avec quelques chiffres précis.Les deux sont de très bonnes lectures.

Answer 5

À mon humble avis:

Lorsque vous utilisez PHP pour le développement Web, la plupart de votre connexion ne "vivra" que pendant la durée de vie de la page en cours d'exécution.Une connexion persistante va vous coûter beaucoup de frais car vous devrez la mettre dans la session ou quelque chose du genre.

Dans 99 % des cas, une seule connexion non persistante qui s'arrête à la fin de l'exécution de la page fonctionnera parfaitement.

L’autre 1 % du temps, vous ne devriez probablement pas utiliser PHP pour l’application, et il n’existe pas de solution parfaite pour vous.

Answer 6

J'allais poser cette même question mais plutôt que de poser à nouveau la même question, je vais simplement ajouter quelques informations que j'ai trouvées.

• Les connexions persistantes PHP sont-elles mauvaises ?
• Connexions persistantes à la base de données

Il convient également de noter que la nouvelle extension mysqli n'inclut même pas la possibilité d'utiliser des connexions persistantes à la base de données.

J'utilise toujours des connexions persistantes pour le moment, mais je prévois de passer à des connexions non persistantes dans un avenir proche.

Answer 7

En général, vous devrez parfois utiliser des connexions non persistantes, et c'est bien d'avoir un modèle unique à appliquer à la conception des connexions de base de données (tant qu'il y a relativement peu d'avantages à utiliser des connexions persistantes dans votre contexte.)