Connexions DB persistantes-oui ou non?
J'utilise la couche PDO de PHP pour l'accès aux données dans un projet, et j'ai lu dessus et vu qu'il a un bon support inné pour les connexions DB persistantes. Je me demande quand / si je devrais les utiliser. Est-ce que je verrais des avantages de performance dans une application CRUD-heavy? Y a-t-il des inconvénients à considérer, peut-être liés à la sécurité?
Si cela vous importe, J'utilise MySQL 5.x.
7 réponses
Vous pouvez l'utiliser comme un brouillon "règles":
OUI, utiliser des connexions persistantes, si:
- Il n'y a que peu d'applications/utilisateurs accédant à la base de données, c'est-à-dire que vous n'obtiendrez pas 200 connexions ouvertes (mais probablement inactives), car il y a 200 utilisateurs différents 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 à la base de données souvent
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 avez plusieurs serveurs web accédant à un serveur de base de données
- vous utilisez Apache en mode prefork. Il utilise une connexion pour chaque processus enfant, ce qui peut augmenter assez rapidement. (via @ Powerlord dans les commentaires)
L'utilisation de connexions persistantes est considérablement plus rapide, surtout si vous accédez au base de données sur 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 encore un peu plus rapide. Cependant - comme le nom l'indique, la connexion est persistante, c'est à dire qu'elle reste ouverte, même si elle n'est pas utilisée.
Le problème avec cela est que dans" 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 - dire - 20 serveurs Web avec chaque 100 Clients sur eux, et chacun d'eux n'a qu'un accès à la page par heure, simple math vous montrera que vous aurez besoin de 2000 connexions parallèles à la base de données. Cela ne marchera pas.
Ergo: utilisez-le Uniquement pour les applications avec beaucoup de demandes.
En bref, mon expérience dit que les connexions persistantes devraient être évitées autant que possible.
Notez que mysql_close est une opération (non-op) pour les connexions sont créées à l'aide de mysql_pconnect. Cela signifie que la connexion persistante ne peut pas être fermée par le client à volonté. 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 à wait_timeout. Si wait_timeout est de grande valeur (disons 30 min) alors mysql db server peut facilement atteindre max_connections Limite. Dans ce cas, mysql db n'acceptera aucune demande de connexion future. C'est quand votre pager commence à biper.
Afin d'éviter d'atteindre la limite max_connections, l'utilisation d'une connexion persistante nécessite un équilibrage minutieux des variables suivantes...
1. Number of apache processes on one host
2. Total number of hosts running apache
3. wait_timout variable in mysql db server
4. max_connections variable in mysql db server
5. Number of requests served by one apache process before it is re-spawned
Donc, pl utiliser une connexion persistante après une délibération suffisante. Vous ne voudrez peut-être pas inviter des problèmes d'exécution Complexes pour un petit gain que vous obtenez de persistent connexion.
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 ASP.Net et Java world, nous avons "connection pooling", ce qui est à peu près la même chose, et aussi une bonne idée.
IMO, la vraie réponse à cette question Est ce qui fonctionne le mieux pour votre application. Je vous recommande de comparer votre application en utilisant des connexions persistantes et non persistantes.
Maggie Nelson @ objectivement orienté posté à ce sujet en août etRobert Swarthout fait un post d'accompagnement avec quelques chiffres durs. Les deux sont très bonnes lectures.
, À 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 généraux car vous devrez le mettre dans la session ou une telle chose.
99% du temps, une seule connexion non persistante qui meurt à la fin de l'exécution de la page fonctionnera très bien.
L'autre 1% du temps, vous ne devriez probablement pas utiliser PHP pour L'application, et là n'est pas une solution parfaite pour vous.
J'allais poser cette même question mais plutôt que de poser la même question à nouveau, je vais simplement ajouter quelques informations que j'ai trouvées.
Il est également intéressant de noter que la nouvelle extension mysqli n'inclut même pas l'option d'utiliser des connexions de base de données persistantes.
J'utilise toujours des connexions persistantes pour le moment mais je prévois de passer à non persistant dans un proche avenir.
En général, vous devrez parfois utiliser des connexions non persistantes, et il est agréable d'avoir un seul modèle à appliquer à la conception de connexion db (tant qu'il y a relativement peu d'avantages à utiliser des connexions persistantes dans votre contexte.)