Votre avis serait le bienvenue afin de bien comprendre l'impacte de PDO::ATTR_PERSISTENT => true en PHP(7) et de savoir si oui ou non il est bon de l'activer.
En effet son activation dans mon script pour checker nextcloud divise par deux le temps de réponse et diminue très fortement le nombre de requêtes reçues par le serveur de base de données.
Néanmoins, difficile de voir si les perfs de nextcloud ont changées ou si cela n'impacte que le script de HealthCheck, le vhost ou tout le serveur web. Les infos n'étant pas récentes et pas très francophone, difficile aussi d'appréhender si cette option est conseillée, a risque ou nécessitant une adaptation (notamment au niveau des timeout) du LoadBalancer et du serveur de BDD.
Quelques infos trouvées sur le nain-terre-net.
Une mise en garde a propos d'ODBC, impossible de savoir si nextcloud est soumis à cet encart
Note:
Si vous utilisez le pilote PDO ODBC et que votre librairie ODBC prend en charge le bassin de connexion ODBC (unixODBC et Windows le supportent tous les deux ; peut être plus), alors il est recommandé de ne pas utiliser les connexions persistantes PDO, mais plutôt laisser le bassin de connexion ODBC mettre en cache les connexions. Le bassin de connexion ODBC est partagé avec les autres modules dans le processus ; si PDO met en cache la connexion, alors cette connexion ne sera jamais retournée par le bassin de connexion ODBC, faisant que plusieurs connexions sont créées pour les autres modules.
source : http://php.net/manual/fr/pdo.connections.php
Une mise en garde à propos des verrous :
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.
source : http://fr2.php.net/manual/fr/features.persistent-connections.php
Cela signifie-t-il qu'il peut y avoir des problèmes de "verrous" nécessitant de reboot la BDD?
Cela signifie-t-il qu'il faut diminuer les timeouts lié a la BDD (qui sont relativement long avec nextcloud) voir ajouter une condition dans le script de HealthCheck afin de désactiver le cache tout les X temps?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.