Passage à MySQL 5.6 : temps de connexion BDD élevé

tu as vérifié que le serveur Sql est bien à Gravelines? 5.6?
j'ai cru comprendre que temporairement, le serveur pouvait rester à Paris, Gra2 communiquant avec lui via un tunnel, ce qui doit ajouter une latence

Comment le vérifier ? si je me connectes sur mon compte j'ai bien ceci :

Datacentre
gra2

J'imagine que je suis bien à Gravelines

Après ce qui me fait penser que c’est bien mysql 5.6 qui pose problème c'est que j'avais constaté le même soucis avec un autre site sur le SQL privé qui était en 5.6. Quand j'allais sur le mutualisé en 5.5 aucun soucis de connexion.

dans 'hébergement/base de données', il est indiqué quoi?
dans un dump de la base, dans les entêtes, il est indiqué le serveur utilisé

Je suis désolé je vois pas où je dois regarder :/

J'ai télécharger une des sauvegarde d'OVH, je l'ai décompressé et édité pour voir son contenu et je ne vois aucun serveur indiqué.

J'ai ceci en entête :

> -- MySQL dump 10.13 Distrib 5.5.62, for debian-linux-gnu (x86_64)
> --
> -- Host: IP* Database: mabdd
> -- ------------------------------------------------------
> -- Server version 5.6.42-log

> /*!40101 SET %OLD_CHARACTER_SET_CLIENT=%%CHARACTER_SET_CLIENT */;
> /*!40101 SET %OLD_CHARACTER_SET_RESULTS=%%CHARACTER_SET_RESULTS */;
> /*!40101 SET %OLD_COLLATION_CONNECTION=%%COLLATION_CONNECTION */;
> /*!40101 SET NAMES utf8 */;
> /*!40103 SET %OLD_TIME_ZONE=%%TIME_ZONE */;
> /*!40103 SET TIME_ZONE='+00:00' */;
> /*!40014 SET %OLD_UNIQUE_CHECKS=%%UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
> /*!40014 SET %OLD_FOREIGN_KEY_CHECKS=%%FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
> /*!40101 SET %OLD_SQL_MODE=%%SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
> /*!40111 SET %OLD_SQL_NOTES=%%SQL_NOTES, SQL_NOTES=0 */;

J'imagine qu'on peux voir ça avec l'IP de l'hôte ?
* je n'ai pas mis l'IP car je ne sais pas si c’est une info qui peut être rendu publique. Mais je peux la mettre si ça ne craint pas.

% = @ (j'ai du modifier pour pouvoir poster ce message

D'ailleurs si dans cet entête tu vois quelque chose d'anormal je suis preneur.

PS : normalement le cluster 005 (selon OVH) était intégralement migré, d'ou mon étonnement si les BDD sont toujours sur P19.

`Server version 5.6.42-log`
5.6, c'est Gravelines à priori

Ok donc au niveau des entêtes aucun soucis et je suis bien sur Gravelines ? (je ne sais pas de quelles entêtes tu parles pour les 2 suivantes ^^ ) Donc le problème reste toujours sans réponse alors :'(

Je gère des sites depuis 15 ans et c'est le problème le plus étrange et complexe auquel j'ai été confronté. J'y suis confronté depuis un bon moment mais jusqu'a présent j'arrivais à gérer car sans faire attention à ça en étant en 5.5 j'avais aucun soucis. Et la je suis vraiment dans l'impasse puisque le 5.6 est la version par défaut maintenant.

Que fait MYSQL lorsqu'il se connecte à une BDD et qu'est ce qui peut le gêner lors de cette étape ?

- Un problème de structure de la BDD ? De charset ?

- La méthode pour se connecter ? (si c'était ça, ça serait du tout ou rien j'imagine ! )
Pour me connecter je fais ceci :

> $debut = microtime(true);
>
> // Création de la connexion
>
> if(defined ('BD_PORT'))
> self::$bdd = new PDO('mysql:host='.BD_SERVEUR.';port='.BD_PORT.';dbname='.BD_NOM.';charset=utf8', BD_UTILISATEUR, BD_PASSE);
> else
> self::$bdd = new PDO('mysql:host='.BD_SERVEUR.';dbname='.BD_NOM.';charset=utf8',
> BD_UTILISATEUR, BD_PASSE);
>
> if(PDOERRMODE==true)
> self::$bdd->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
> else
> self::$bdd->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_SILENT);
>
> $fin = microtime(true);
> $time = $fin - $debut;


Quelle différence entre Mysql 5.5 et 5.6 existe qui pourrait être associable à ce problème ?
je ne suis vraiment pas expert du fonctionnement de l'architecture de MySQL

c'était des exemples pour info que je montrais, je les enlèves
je ne suis pas compétent pour parler d'optimisation

Bonjour, je ne vois pas où se situe le problème en réalité ? En allant sur l'adresse fournie le site se comporte parfaitement et le chargement des pages est très fluide. Ou alors je ne me rends sur les bonnes pages ?!
Quelle version de php pour votre site ? Structure de la bdd en myisam ? innodb ? les index sont bien en place ? jointures (si innodb) en place ?

Le problème vient du fait que dans la journée j'ai plus de 40 fois par jour (sur seulement 300v/jour) des connexions à la bdd qui mettent entre 200ms et 1s et que ca s'aggrave petit à petit. 200ms ou 800ms ca ne se voit pas forcément non plus pour un visiteur. D'autant plus si c'est pas systématique à chaque nouvelle page affichée. Il y a un côté aléatoire qui rend le problème d'autant plus complexe à cerner.

Fin février (début de la migration sur Graveline et mysql 5.6) c'était essentiellement autour de 200ms et maintenant c'est très souvent autour des 800ms. Et ces temps de connexion anormaux sont de plus en plus fréquents.
J'avais déjà eu ce problème sur un SQL privé en mysql 5.6 pour un autre site, c'était monté petit a petit jusqu'à des 7s rien que pour se connecter, voir même des time out.

Et la ça suit le même chemin. Donc logique que tu ne te rendes pas compte pour le moment du soucis juste en surfant comme ça sur le site. ;)

Sinon je suis en Myisam, mes index sont bien en place et j'ai fait des Explain pour chacune de mes requêtes. Mais pas certain que mes requêtes dans le cas présent sont à remettre en cause.
Est-ce que les Index peuvent avoir une répercussion sur la connection à la BDD ?
et pourquoi ce problème en mysql 5.6 et pas en 5.5 ?

@Kyodev là je crois que ça sort du cas de l'optimisation mais d'un soucis technique. Un truc qui coince à un endroit, mais où chercher ! :/ Qu'est-ce qui peut affecter la connexion.

De toute manière vous n'aurez jamais (ou difficilement) un timing de chargement identique en fonction des connexions car cela dépend de nombreux facteurs comme les accès disques, la bande passante dispo, le débit de la connexion du client ou du serveur à un instant T etc... prenez donc en exemple d'autres sites et vous tomberez sur la même problématique.
Après que vous n'ayez pas constaté cela sur la précédente version de mysql est autre chose, cela m'étonne d'autant +.
Je vois, en consultant votre page, que vous faites appel à des librairies externes (telles que googleapi) qui peuvent par moment ralentir les perfs (même si encore une fois je doute que ce soit vraiment le fond du problème).
Quoi qu'il en soit et de mon point de vue, après avoir lancé un benchmark de votre site je tombe en moyenne, sur 200 appels (sans cache), sur un temps de chargement de 280ms. Le maximum a été 300ms. N'ayant pas la main sur votre serveur je ne pourrais faire de tests plus poussés mais à première vue cela semble correct. Peut être que votre serveur a un peu plus de mal lorsque de "nombreux" visiteurs sont présents en même temps ?

Je pense vraiment pas que ça soit normal ou lié a l'environnement ou je ne sais quoi. De plus on parle ici de temps e connexions qui approche de plus en plus souvent les 1s. Sachant que ça s'aggrave avec le temps.
Le problème c'est d'arriver à faire reconnaître qu'il y a un soucis et qu'il soit en plus identifié. Surtout quand c'est aléatoire et aussi farfelu que ça.
J'ai peu de visites par jour 300 environ et donc rarement en simultanés (même si on prend en compte les bots). Donc ça n'explique pas toutes les fois par jour ou la connexion a mis plus de 200ms. Je compte plus de 40 enregistrements dans mes logs.

Ces temps de connexion élevés apparaissent aussi plus facilement a la première connexion d'un utilisateur (même si c’est pas systématique). Par conséquent faire 200 accès en peu de temps sera assez peu concluant.

En plus comme indiqué ça s'aggrave avec le temps. Je veux donc réagir avant de me retrouver avec des accès qui mettent plusieurs secondes. ;)

J'ai remarqué ceci en faisant un SHOW STATUS sur la BDD en mySQL en 5.6:

> Performance_schema_accounts_lost => 0
> Performance_schema_cond_classes_lost => 33
> Performance_schema_cond_instances_lost => 0
> Performance_schema_digest_lost => 1793016
> Performance_schema_file_classes_lost => 36
> Performance_schema_file_handles_lost => 63
> Performance_schema_file_instances_lost => 53
> Performance_schema_hosts_lost => 29375
> Performance_schema_locker_lost => 0
> Performance_schema_mutex_classes_lost => 145
> Performance_schema_mutex_instances_lost => 0
> Performance_schema_rwlock_classes_lost => 20
> Performance_schema_rwlock_instances_lost => 1043297
> Performance_schema_session_connect_attrs_lost => 0
> Performance_schema_socket_classes_lost => 0
> Performance_schema_socket_instances_lost => 114
> Performance_schema_stage_classes_lost => 0
> Performance_schema_statement_classes_lost => 0
> Performance_schema_table_handles_lost => 0
> Performance_schema_table_instances_lost => 26505
> Performance_schema_thread_classes_lost => 9
> Performance_schema_thread_instances_lost => 617
> Performance_schema_users_lost => 2207

J'avais identifié le même problème lorsque j'avais essayé le SQL Privé sous MySQL 5.6. J'essayerais bien le Privé sous 5.7 mais si c'est pire je pourrais même plus revenir en arrière.

Par contre si j'essaye sur un autre site qui n'a pas encore migré sur Gravelines et qui est en mysql 5.5 j'ai ceci :

> Performance_schema_cond_classes_lost => 0
> Performance_schema_cond_instances_lost => 0
> Performance_schema_file_classes_lost => 0
> Performance_schema_file_handles_lost => 0
> Performance_schema_file_instances_lost => 0
> Performance_schema_locker_lost => 0
> Performance_schema_mutex_classes_lost => 0
> Performance_schema_mutex_instances_lost => 0
> Performance_schema_rwlock_classes_lost => 0
> Performance_schema_rwlock_instances_lost => 0
> Performance_schema_table_handles_lost => 0
> Performance_schema_table_instances_lost => 0
> Performance_schema_thread_classes_lost => 0
> Performance_schema_thread_instances_lost => 0

Les 2 sites sont pourtant codés de la même façon même au niveau de la BDD.

Pour moi il y a quelque chose à identifier à ce niveau là. Je l'avais aussi signalé lorsque j'avais testé le SQL privé avec MYsql 5.6 mais le support n'avais pas réagit à ça.
Le problème c'est que je n'y connais rien en Gestion de Serveur MySQL et je ne sais pas comment analyser le SHOW STATUS.

Le fait que j'ai des soucis avec les tables performance de Mysql pour une raison que j'ignore me semble cohérent avec les soucis de connexion et ce "goulot d’étranglement qui s'installe". C'est peut être lié aux tables de Performances de SQL qui deviennent trop lourdes.

Le truc, c'est de comprendre pourquoi il y a ces erreurs qui sont enregistrées dans "Performances" et comment l'analyser.

Je suis peut être sur une mauvaise piste, mais ça me semble intéressant à creuser.

@popallo et @kyodev je suis désolé de vous demander ça car c'est déjà sympa de m'avoir répondu, mais pourriez vous tester (si vous avez vos bdd sur mysql 5.6) Show Status pour voir si vous aussi vous avez des valeurs enregistrées et élevées pour les lignes concernant Peformance_Schema, ça m'aiderait peut être à savoir si je suis sur une bonne piste ou non. Car j'ai cru comprendre que Performance_schema était activé par défaut à partir de 5.6. Donc ca pourrait expliquer cette difference de show status entre mysql 5.5 et 5.6.

Parceque ce genre de ligne me parait anormal :
Performance_schema_rwlock_instances_lost => 1043297
Performance_schema_digest_lost => 1793016
Mais les autres également

```text
mysql -e 'select version()' | grep -v version
5.6.39-log

mysql -e 'show status' | grep -i performance
Performance_schema_accounts_lost 582035
Performance_schema_cond_classes_lost 33
Performance_schema_cond_instances_lost 0
Performance_schema_digest_lost 540019447
Performance_schema_file_classes_lost 36
Performance_schema_file_handles_lost 203
Performance_schema_file_instances_lost 194
Performance_schema_hosts_lost 3071895
Performance_schema_locker_lost 0
Performance_schema_mutex_classes_lost 145
Performance_schema_mutex_instances_lost 0
Performance_schema_rwlock_classes_lost 20
Performance_schema_rwlock_instances_lost 400890961
Performance_schema_session_connect_attrs_lost 0
Performance_schema_socket_classes_lost 0
Performance_schema_socket_instances_lost 614426
Performance_schema_stage_classes_lost 0
Performance_schema_statement_classes_lost 0
Performance_schema_table_handles_lost 0
Performance_schema_table_instances_lost 853109
Performance_schema_thread_classes_lost 9
Performance_schema_thread_instances_lost 745273
Performance_schema_users_lost 1484268
```

pour info, un autre site visité, sur un autre serveur:
```text
mysql -e 'select version()' | grep -v version
5.7.24-log

mysql -e 'show status' | grep -i performance
Performance_schema_accounts_lost 0
Performance_schema_cond_classes_lost 0
Performance_schema_cond_instances_lost 0
Performance_schema_digest_lost 172875971
Performance_schema_file_classes_lost 0
Performance_schema_file_handles_lost 0
Performance_schema_file_instances_lost 178648
Performance_schema_hosts_lost 0
Performance_schema_index_stat_lost 0
Performance_schema_locker_lost 0
Performance_schema_memory_classes_lost 0
Performance_schema_metadata_lock_lost 0
Performance_schema_mutex_classes_lost 0
Performance_schema_mutex_instances_lost 0
Performance_schema_nested_statement_lost 0
Performance_schema_prepared_statements_lost 0
Performance_schema_program_lost 0
Performance_schema_rwlock_classes_lost 0
Performance_schema_rwlock_instances_lost 0
Performance_schema_session_connect_attrs_lost 0
Performance_schema_socket_classes_lost 0
Performance_schema_socket_instances_lost 0
Performance_schema_stage_classes_lost 0
Performance_schema_statement_classes_lost 0
Performance_schema_table_handles_lost 0
Performance_schema_table_instances_lost 0
Performance_schema_table_lock_stat_lost 0
Performance_schema_thread_classes_lost 0
Performance_schema_thread_instances_lost 0
Performance_schema_users_lost 0
```
je n'ai pas de compétences pour analyser ça

Bonjour, de mon côté je désactive performance schema car je ne m'en sers pas et cela augmente la consommation de ram et baisse les perfs de manière significative (tout du moins sur les serveurs que j'administre, que ce soit sous mariadb ou mysql).

Bonjour,
@Saxgard: Je ne pense pas que cela soit lié à la version de MySQL.
Apparemment ton site et et base de données ont été migré vers Gravelines courant Février 2019.

Dans le code source que tu met plus haut, tu mesures le temps de connexion à MySQL, si c'est ce temps qui varie de 200ms à 1000ms, ce n'est effectivement pas normal et toutes les optimisations que tu feras n'auront pas d'effet sur la vitesse de connexion.

tu peux essayer de loguer les temps de connexion dans un fichier,
dessous "$time = $fin - $debut;" tu peux ajouter par exemple :
```
$time = round($time * 1000, 1);

if( $time > 100 ){
file_put_contents("time_connect.txt", date('r') . " - $time ms\n", FILE_APPEND);
}
```

Cordialement,
Boris.

J'ai trouvé un de mes serveurs (mysql 5.7.25) où performance schema est activé :
```
Performance_schema_accounts_lost
0
Performance_schema_cond_classes_lost
0
Performance_schema_cond_instances_lost
0
Performance_schema_digest_lost
0
Performance_schema_file_classes_lost
0
Performance_schema_file_handles_lost
0
Performance_schema_file_instances_lost
0
Performance_schema_hosts_lost
0
Performance_schema_index_stat_lost
0
Performance_schema_locker_lost
0
Performance_schema_memory_classes_lost
0
Performance_schema_metadata_lock_lost
0
Performance_schema_mutex_classes_lost
0
Performance_schema_mutex_instances_lost
0
Performance_schema_nested_statement_lost
0
Performance_schema_prepared_statements_lost
0
Performance_schema_program_lost
0
Performance_schema_rwlock_classes_lost
0
Performance_schema_rwlock_instances_lost
0
Performance_schema_session_connect_attrs_lost
0
Performance_schema_socket_classes_lost
0
Performance_schema_socket_instances_lost
0
Performance_schema_stage_classes_lost
0
Performance_schema_statement_classes_lost
0
Performance_schema_table_handles_lost
0
Performance_schema_table_instances_lost
0
Performance_schema_table_lock_stat_lost
0
Performance_schema_thread_classes_lost
0
Performance_schema_thread_instances_lost
0
Performance_schema_users_lost
0
```
Et pour la petite histoire, performance schema permet (entre autre) d'être utilisé pour comparer le temps d’exécution des requêtes.
Cela ne devrait pas, à mon sens, être utilisé sur du serveur en production (autrement que pour effectuer une phase d'optimisation et faire du monitoring).

@kyodev si je comprends bien tu vois la même chose concernant performance schéma pour d'autres site en Mysql 5.6 ?
Je pourrais en déduire que la piste des performance_schema n'est la bonne j'imagine. Même si je ne comprend pas comment ça se fait que @popallo a 0 partout sur du mysql 5.7 alors que Performance_Schema est aussi activé. Popallo tes serveurs sous mysql 5.7 c’est sur du SQL privé ? du dédié ?

J'ai encore du mal à savoir ce que je dois tirer de tout ça et si je dois chercher plus profondément du côté de ce Performance_schema ou si j'évite de perdre du temps la dessus. :'(

@BorisM il est bien là le problème c'est que je sais que ces temps de connexion aléatoires élevés ne sont pas normaux mais je ne sais absolument pas ou chercher. Autant une requête gourmande je peux travailler dessus pour l'optimiser mais là j'ai 0 piste. Ou si je n'arrivais tout simplement pas a me connecter ça serait également plus simple pour trouver la source du problème.
Au niveau de la structure de la BDD ou au niveau du code PHP qu'est-ce qui pourrait bien provoquer des lenteurs de connexions aléatoires et qui semblent s'aggraver avec le temps ?
J'ai quand même l'impression que la version MySql joue un rôle puisque j'avais constaté le même soucis sur un SQL privé avec mysql 5.6.
Qu'est qui différencie la 5.6 a la 5.5 qui pourrait avoir un lien avec ce problème ?
La le soucis c'est que Mysql 5.5 n'est plus dispo sur OVH et je suis au pied du mur. Je n'ai plus le choix, je dois identifier le problème car je n'ai plus de solution de secours en tout cas sur OVH.
Sinon je logue bien mes temps de connexion, c'est comme ça que je me suis rendu compte du problème et que je suis capable de dire que j'ai plus de 40-50 enregistrements dans les logs par jour de connexions qui ont été trop lentes sur seulement 300 v/j .

Très difficile d'identifier un tel problème quand on n'est pas administrateur de BDD et sur mutualisé.

Un problème qui sort du cadre de mes compétences. Je ne sais plus quoi faire. :/
Pour moi seul OVH pourrait avec leurs logs système etc. identifier le problème ou me donner des pistes mais je n'obtiens rien de leur part.

De mon côté le mysql 5.7 se trouve sur un dédié et pas des plus perfs :D (kimsufi). Environ 15 bdd dessus, des sites avec un traffic pas très élevé (pas plus de 100cnx/jour/site).

N'avez-vous pas la possibilité de tester avec mariadb ? Sur mariadb, sauf si OVH a modifié la configuration à ce niveau là, peu importe la version le perf schema n'est pas actif par défaut.

Je ne sais pas si sur mutualisé on peut passer sur du MariaDB mais j'ai pas l'impression.

Et sur le Sql Privé le soucis c'est que c'est irreversible. Donc si j'ai un soucis plus grave avec MariaDB ou même Mysql 5.7 il n'y a aucun moyen de changer de version sql ensuite . :/

Vraiment pas simple... :/

Pour un mutualisé il est certain que non :) pour le sql privé par contre je suis surpris d'un tel fonctionnement (que l'on ne puisse pas switcher entre mariadb ou mysql .. que ce soit irréversible). Après je ne possède pas une telle offre donc je n'en connais pas le fonctionnement malheureusement.

En effet sur Sql Privé si on est sur du 5.6 on peut seulement passer sur du 5.7 mais on ne peut pas repasser sur du 5.6 ou sur du MariaDB.

De mon point de vue, après ne pouvant faire de benchmark je ne peux pas vous le confirmer mais, performance schema a été introduit sur mysql 5.5 et non activé par défaut. Puis reporté (màj) sur 5.6 et activé par défaut et enfin reporté (màj) sur 5.7 et activé aussi par défaut.
Les différences entre 5.6 et 5.7 ne sont pas "majeures" mais sur certains benchmark que j'ai pu faire la v5.7 améliore les performances et des notes concernant une meilleure optimisation de performance schema sont présentes dans leur "what's new" (cf ce lien https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html).
J'ose penser que passer à 5.7 n'irait pas dégrader plus que le passage de 5.5 à 5.6 qui lui pouvait avoir un impact certain (et pas forcément visible de tous).

C'est interessant merci. Quoi qu'il en soit le fait que performance_schema est activé depuis mysql 5.6 semble être une "petite" piste interessante même si j'ai encore du mal à voir comment ça peut avoir une incidence sur ma connexion à la bdd.

D'ailleurs est-ce que performance_schema est commun sur mutualiséou on a chacun la notre ?

Pour faire un test, peut-on désactiver performance_schema sur mutualisé (j'en doute) ou au moins sur sql privé (j'en doute aussi) ? Et si oui comment ?

Un autre test que je ne peux pas effectuer et qui aurait été interessant c'est que d'autres membres d'ovh sur mutualisé (voir même sql privé) et mysql 5.6 verifie le temps de connection uniquement (et pas des requete) pendnat 24h avec un log pour voir si ils détectent aussi ces temps de connexion elevés aléatoires.. :/

La je ne sais vraiment pas comment m'y prendre pour savoir si ca vient de la structure de ma bdd qui crée un conflit, de charset, de mon code php, d'un probleme lié à ovh ou je ne sais quoi encore...
Le fait d'identifier que le probleme semble surtout présent à partir de mysql 5.6 est une piste mais ça reste très léger et vague.

Performance schéma se désactive via la configuration de MySQL en ajoutant performance_schema = 0 et en redémarrant le serveur SQL. Sur le mutu c'est sûr que vous n'y aurez pas accès et le SQL privé je ne saurais dire, avez vous accès ssh sur le serveur SQL et pouvez vous modifier la conf ?
Pur ce qui est de l'impact de performance schéma il n'est pas négligeable vu qu'en quelques sortes MySQL va écrire ses rapports dans une table alors même que vous avez du traffic. Donc si votre site, pour x ou y raison, connait des pertes mémoire ou autre cela peut générer une trace dans performance_schema et je ne doute pas que cela puisse avoir un impact plutôt "négatifs".
L'idéal pour vous serez de pouvoir, au moins temporairement, déporter votre base de données sur un serveur SQL autre que ceux que vous utilisez actuellement sauf si vous avez un minimum la main sur la conf du SQL privé.

Le bon sens voudrait que, sur un mutualisé, le performance schema soit partagé entre tous. Un serveur SQL pour plusieurs utilisateurs.
Pour le privé du coup il doit vous être propre.

Quoi qu'il en soit il serait intéressant d'avoir l'avis d'un tech de chez OVH car n'ayant pas la main sur les machines, ne pouvant réaliser de benchmark, ce que je dis et donne comme avis n'est que purement spéculatif.

Mes connaissances en MySQL s'arrêtent à configurer et optimiser un serveur sur un dédié / VPS. Je savais juste que l'activation de performance schema a levé pas mal de discussion et notamment en ce qui concerne sa désactivation par défaut. Mais ORACLE persévère dans ce choix, surement pour de bonnes raisons (j'espère en tout cas).

Encore merci pour tes réponses. J'essayerais de voir si je peux le désactiver sur le SQL privé et si ça change quoi que ce soit. Mais j'ai quand même de gros doutes.

Question peut être un peu bête mais comment savoir si notre BDD est compatible avec une nouvelle version de MySQL ? En gros comment puis je savoir si ma BDD est bien compatible avec mysql 5.6 ? Et comment détecter les incompatibilités éventuelles ?
la seule chose qui peut être incompatible c'est la structure de la bdd non ?
Qu'est-ce qui aurait changé dans la façon de structurer sa bdd qui aurait changer depuis les dernières versions de MySQL ?
Et est-ce qu'une structure inadéquate pourrait provoquer des lenteurs de connexion ?

Je sais qu'en mysql 5.7 le sql_mode est actif par défaut et pose des soucis au niveau de certains champ qui non pas de valeur par défaut et les champs date également. Mais à part ça je ne vois pas très bien.

> j'ai quand même de gros doutes

c'est fort d'avoir des doutes sans expériences alors que popallo l'a...

Ah nonnn pas du tout je ne remet pas en cause les propos de popallo, mais je ne suis juste pas certain que l'activation de performance_schema soit lié a ce problème de connexion qui s'aggrave avec le temps. D'ailleurs popallo ne me dit pas qu'il pense que c'est lié non plus. Il m'a juste donné des infos sur performance_schema. ;)
Et je compte bien tester en le désactivant (si je peux) . Après je croise évidemment les doigts que ça soit une bonne piste vu que j'en ai aucune autre.

Loin de moi l'idée de remettre en cause les compétences de ceux qui viennent me donner un coup de main. Et je n'ai pas compris comment tu en es arrivé à cette conclusion. ^^

ok, j'avais pas compris, je rentre les griffes du chat à popallo, et je le lancerai pas sur toi :)

:D aucun soucis
Je suis déjà bien content qu'on me réponde et qu'on essaye de m'aider :) ca me permet d'avancer, d'avoir des bases de réflexion.
Surtout que je suis pas mal en stress avec ce problème. :'(
D'autant plus que bientôt tous mes autres sites vont aussi migrer sur Gravelines et donc en Mysql 5.6... ca met une sacré pression.

Si vous souhaitez tester la compatibilité, je vous recommande d'installer un serveur mysql en local sur votre ordinateur avec la version ciblée de mysql disponible sur le système de production. Cela vous permettra de tester que l'import se fait bien.
La grosse différence que j'ai pu noter est une évolution considérable des performances du moteur innodb, encore faut-il utiliser correctement les index / clé étrangères / jointures et configurer un peu (quand cela est possible) en fonction du besoin. Il a souvent été dit que myisam était plus performant (ce qui est encore vrai dans certains cas de figure) mais il est dorénavant fortement recommandé d'avoir une structure de bdd sous innodb (gestion des transactions entre autre).
Sinon ils font à chaque fois pas mal de correction mais je ne saurai lister le détail précis. L'information doit pouvoir se trouver sur leur site officiel.
Je ne dis en effet pas que performance schema est responsable mais c'est une piste non négligeable quoi qu'il en soit.

Encore merci je vais étudier toutes ces pistes :

- Désactivation de Performances_Schema
- Test en local avec le Mysql 5.6 (la je suis en Mysql 5.7 via Wampserver), mais la aussi il me semble que sur mon ancien PC j'avais une version avec mysql 5.6 et je n'avais pas ce soucis. je vérifierais à nouveau.
- Tests de connexion sur une BDD vide sans tables et sur une autre BDD (exemple wordpress) plutôt que ma BDD/framework personnel
- Mysql 5.7
- MariaDB
- MyIsam -> Innodb (mais ça j'avais déjà essayé sur le SQL privé avec mysql 5.6 et je n'avais pas eu de résultat concluant)

Tout ça va prendre du temps à tester et beaucoup de rigueur :/
Surtout quand on est sur mutualisé et qu'on peut pas tout tester comme on le souhaite.
Et c'est d'autant plus compliqué à tester et identifier quand il n'y a aucun soucis en local.

J'ai aussi créé un Ticket il y a 2 jours mais bon... on sait déjà où ça va mener (sachant aussi que le temps de réponse va mettre des plombes). Lorsque j'avais signalé le soucis sur le SQL privé, après un ping pong de plusieurs semaines ça n'avait aboutit à rien. Leur conclusion : serveurs vieillissant sur P19, le passage à Gravelines devrait arranger les choses !

Je reste évidemment ouvert à d'autres conseils/pistes

Peut être serait il temps de penser à passer sur un serveur dédié ? Le coût n'est pas le même mais en fonction du besoin ça peut être limite plus rentable. Et puis au moins vous avez quasi intégralement la main sur la machine. Je dis "intégralement" car reste le réseau qui est dépendant du fournisseur, la qualité des composants mis en place, ... mais pour tout ce qui est logiciel, configuration c'est à votre main :)
Et si pas le temps ou l'envie de gérer votre propre serveur, le faire managé par quelqu'un. Cela augmente encore un peu le coût mais permet d'avoir quelque chose d'adapté et optimisé (enfin dépend du prestataire qui vous fait cela, bien évidemment).

Sinon bon courage pour vos recherches, n'hésitez pas à venir nous faire part de vos résultats.

Merci beaucoup. Pour un dédié j'y ai pensé à de nombreuses reprises mais malheureusement je serais incapable de l'administrer et effectivement ça augmenterait très vite les coûts de passer par de l'infogérance. :/
Donc entre les coûts, le temps et le stress de gérer le dédié je ne suis pas certain que pour moi (pour le moment) ca soit la solution idéale. ^^ D'autant plus que mes sites ne sont pas particulièrement gourmand et on assez peu de visiteurs (quelques centaines par jour).

Bon là je suis en train d'essayer de comprendre comment activer/desactiver performance schema en local :/
Sur WampServer il n'y a pas de fichier my.cnf, mais seulement my.ini.
Quand je vais dans my.ini il n'y a aucune ligne concernant performance_schema

Et si je rajoute ceci (pour essayer dans un premier temps de l'activer pour voir si des chiffres grimpes quand je fais SHOW STATUS) en dessous de [mysqld] :
performance_schema = 1

Il ne se passe rien de spéciale, les valeurs dans performance_schema sont toujours toutes à 0 et je ne sais même pas en fin de compte si c'est bien activé ou non. "je ne suis pas sorti du sable".
Donc soit ma BDD en local (sur mysql 5.7) ne provoque aucune erreur qui s'enregistre dans perf_sch soit ce n'est pas activé sur WampServer et je ne sais pas comment faire.
faudrait que je regarde sur mon autre PC avec un plus vieux wampserveur sous mysql 5.6 (car je ne sais pas comment ajouter plusieurs versions mysql sur wampserver et je voudrais éviter de mettre la pagaille sur mon serveur web local actuel)

Il faut faire une requête "SHOW VARIABLES LIKE 'performance_schema';" pour voir si c'est activé ou non. Pour wamp je n'utilise pas non plus mais le my.ini doit être le bon fichier. En mettant performance_schema = 1 ou 0 cela doit modifier le résultat de la requête que je viens de mettre en début de ce message. Après avoir fait la modification il faut penser à redémarrer le serveur SQL. A tester.

@popallo ah oui merci, effectivement j'ai vu ça après avoir posté ici :
https://dev.mysql.com/doc/refman/5.5/en/performance-schema-quick-start.html
Bon à priori j'arrive bien en local à désactiver ou activer Performance_schema mais ça ne change rien (du moins sur mysql 5.7 avec Wampserver)
les lignes de perf_sch restent à 0
Faut donc que j'essaye avec 5.6 en local, mais pour le moment rien de concluant.

@VincentB4 : Oui passage en mysql 5.6 obligatoire. On ne te laisse pas le choix. Si t'as une offre performance tu peux faire des tests avec SQL privé sous mysql 5.6 pour voir si ça va passer ou non.

le passage vers mysql 5.6 est obligatoire ?

oui, si Sql mutu

php5.4, on peut pas dire que tu as préparé/anticipé... https://docs.ovh.com/fr/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/

La table performance_schema ne se rempli pas si votre serveur n'a ni perte mémoire ni latence ni rien d'autre qui nécessite de logguer des erreurs. C'est uniquement fait pour ça. En local, vous êtes seuls sur votre machine donc en effet, ça ne sera pas très pertinent.
Le but de la manœuvre en local est surtout de voir si vous pouvez passer sur mysql 5.7 sans pertes de données ou autre au final, faire un benchmark alors que vos conditions hardware ne sont pas les mêmes que chez ovh risquent d'être inutiles malheureusement.
Ce que je me demande réellement maintenant c'est si OVH utilise performance schema pour optimiser les bases de données de ses serveurs.

C'est un sujet délicat et difficile. Les mises à jour de versions d'un logiciel sont censées (je dis bien censées..) améliorer les performances, la maintenabilité, la sécurité etc... cela est complètement indépendant de la volonté d'ovh que de mettre à disposition un logiciel "à jour" qui, malheureusement dans certains cas, baissent les performances d'un projet.
Là où OVH n'assure pas, à mon sens, c'est sur le suivi de ces incidents que vous remontez. Après c'est encore un sujet difficile à aborder car ils ne sont pas censés vérifier votre code source et il se peut très bien, dans le cas de @Saxgard par exemple, que ce soit un problème de code. (je ne dis pas que c'est le cas, ne pas me faire dire ce que je ne dis pas)
Je ne dis donc pas que le code est mauvais, loin de moi cette idée, mais peut être malheureusement pas "optimisé" pour le fonctionnement d'un serveur SQL > 5.5. Et que ce soit ovh ou concurrents, ceux-ci n'iront pas vérifer le code d'un projet pour s'assurer de ça. Notamment dans le cadre d'un serveur mutualisé. Ils le feront (peut être ???) si de nombreuses personnes viennent se plaindre. Et encore ... le doute est permis.
Il serait intéressant, si le cas s'est présenté, qu'une personne témoigne d'une amélioration de perf de son projet sur un mysql > 5.5 sur un serveur d'ovh. Mais je doute que les gens, pour qui ça fonctionne bien, viennent ici :)

Donc personnellement ce que j'attends d'un hébergeur c'est de ne pas casser quelque chose qui fonctionne très bien, et d'assurer en permanence la rétro-compatibilité lors de ses diverses opérations de maintenance ...

un hébergeur doit se conformer aux livraisons des programmes, pas à tes souhaits
consultes php.net, tu verras que php est déprécié jusqu'à 7.0

avoir un site est un responsabilité dont une est de le maintenir...
heureusement, sinon on serait en php3 :/

c'est ton avis, on se s'étonnera pas après si les sites sont infectés
et toi qui sais, Ovh maintient quelles versions de Php?

Entrer dans ce débat ne fera pas avancer le problème de notre ami @Saxgard :D

Bon comme prévu en local mes tests et vérifications vis à a vis de Performance_Schema n'ont rien donné. Que ca soit sous 5.6 et 5.7 tout reste a 0 et ca ne change rien que je l'active ou non. En local c'était, comme dit popallo, à prévoir.

Je suis donc aussi allé voir du côté du SQL privé d'un autre de mes sites (son SQL mutualisé étant encore sous mysql 5.5) qui a le même soucis et qui est également sous mysql 5.6.
Je ne vois aucun moyen de désactiver Performance_Schema que ça soit via le manager d'OVH ou même via SFTP. il n'y a pas de fichier ini ou cnf.
Mais je sais maintenant que le Perf_Sch est aussi individuel et non mutualisé sur le SQL Privé (j'étais pas certain). Pour le vérifier j'ai redémarré il y a quelques dizaines de minutes et j'ai donc vu que les valeurs se re-initialisaient. Et en essayant de me connecter sur une BDD vide (sans table ni données) sur ce SQL privé j'ai donc toujours des temps de connexions parfois élévés. Juste avant de poster je suis même tombé sur du 2s.
J'avais déjà parlé de ce problème identique rencontré sur le SQL Privé ici : https://community.ovhcloud.com/community/fr/lenteurs-frequentes-connexion-bdd-sql-prive-allo-le-support?id=community_question&sys_id=18de65c058da42d02d4c51cec5fc96ad

Je vois également ceci en faisant un SHOW STATUS (sachant que j'ai redemarré le serveur il y a 20-30 minutes :

Aborted_clients => 0
Aborted_connects => 6
Binlog_cache_disk_use => 0
Binlog_cache_use => 0
Binlog_stmt_cache_disk_use => 0
Binlog_stmt_cache_use => 0
Bytes_received => 156
Bytes_sent => 104
Com_admin_commands => 0
Com_assign_to_keycache => 0
Com_alter_db => 0
Com_alter_db_upgrade => 0
Com_alter_event => 0
Com_alter_function => 0
Com_alter_procedure => 0
Com_alter_server => 0
Com_alter_table => 0
Com_alter_tablespace => 0
Com_alter_user => 0
Com_analyze => 0
Com_begin => 0
Com_binlog => 0
Com_call_procedure => 0
Com_change_db => 0
Com_change_master => 0
Com_check => 0
Com_checksum => 0
Com_commit => 0
Com_create_db => 0
Com_create_event => 0
Com_create_function => 0
Com_create_index => 0
Com_create_procedure => 0
Com_create_server => 0
Com_create_table => 0
Com_create_trigger => 0
Com_create_udf => 0
Com_create_user => 0
Com_create_view => 0
Com_dealloc_sql => 0
Com_delete => 0
Com_delete_multi => 0
Com_do => 0
Com_drop_db => 0
Com_drop_event => 0
Com_drop_function => 0
Com_drop_index => 0
Com_drop_procedure => 0
Com_drop_server => 0
Com_drop_table => 0
Com_drop_trigger => 0
Com_drop_user => 0
Com_drop_view => 0
Com_empty_query => 0
Com_execute_sql => 0
Com_flush => 0
Com_get_diagnostics => 0
Com_grant => 0
Com_ha_close => 0
Com_ha_open => 0
Com_ha_read => 0
Com_help => 0
Com_insert => 0
Com_insert_select => 0
Com_install_plugin => 0
Com_kill => 0
Com_load => 0
Com_lock_tables => 0
Com_optimize => 0
Com_preload_keys => 0
Com_prepare_sql => 0
Com_purge => 0
Com_purge_before_date => 0
Com_release_savepoint => 0
Com_rename_table => 0
Com_rename_user => 0
Com_repair => 0
Com_replace => 0
Com_replace_select => 0
Com_reset => 0
Com_resignal => 0
Com_revoke => 0
Com_revoke_all => 0
Com_rollback => 0
Com_rollback_to_savepoint => 0
Com_savepoint => 0
Com_select => 0
Com_set_option => 1
Com_signal => 0
Com_show_binlog_events => 0
Com_show_binlogs => 0
Com_show_charsets => 0
Com_show_collations => 0
Com_show_create_db => 0
Com_show_create_event => 0
Com_show_create_func => 0
Com_show_create_proc => 0
Com_show_create_table => 0
Com_show_create_trigger => 0
Com_show_databases => 0
Com_show_engine_logs => 0
Com_show_engine_mutex => 0
Com_show_engine_status => 0
Com_show_events => 0
Com_show_errors => 0
Com_show_fields => 0
Com_show_function_code => 0
Com_show_function_status => 0
Com_show_grants => 0
Com_show_keys => 0
Com_show_master_status => 0
Com_show_open_tables => 0
Com_show_plugins => 0
Com_show_privileges => 0
Com_show_procedure_code => 0
Com_show_procedure_status => 0
Com_show_processlist => 0
Com_show_profile => 0
Com_show_profiles => 0
Com_show_relaylog_events => 0
Com_show_slave_hosts => 0
Com_show_slave_status => 0
Com_show_status => 1
Com_show_storage_engines => 0
Com_show_table_status => 0
Com_show_tables => 0
Com_show_triggers => 0
Com_show_variables => 0
Com_show_warnings => 0
Com_slave_start => 0
Com_slave_stop => 0
Com_stmt_close => 0
Com_stmt_execute => 0
Com_stmt_fetch => 0
Com_stmt_prepare => 0
Com_stmt_reprepare => 0
Com_stmt_reset => 0
Com_stmt_send_long_data => 0
Com_truncate => 0
Com_uninstall_plugin => 0
Com_unlock_tables => 0
Com_update => 0
Com_update_multi => 0
Com_xa_commit => 0
Com_xa_end => 0
Com_xa_prepare => 0
Com_xa_recover => 0
Com_xa_rollback => 0
Com_xa_start => 0
Compression => OFF
Connection_errors_accept => 0
Connection_errors_internal => 0
Connection_errors_max_connections => 0
Connection_errors_peer_address => 0
Connection_errors_select => 0
Connection_errors_tcpwrap => 0
Connections => 199
Created_tmp_disk_tables => 0
Created_tmp_files => 5
Created_tmp_tables => 0
Delayed_errors => 0
Delayed_insert_threads => 0
Delayed_writes => 0
Flush_commands => 1
Handler_commit => 0
Handler_delete => 0
Handler_discover => 0
Handler_external_lock => 0
Handler_mrr_init => 0
Handler_prepare => 0
Handler_read_first => 0
Handler_read_key => 0
Handler_read_last => 0
Handler_read_next => 0
Handler_read_prev => 0
Handler_read_rnd => 0
Handler_read_rnd_next => 0
Handler_rollback => 0
Handler_savepoint => 0
Handler_savepoint_rollback => 0
Handler_update => 0
Handler_write => 0
Innodb_buffer_pool_dump_status => not started
Innodb_buffer_pool_load_status => not started
Innodb_buffer_pool_pages_data => 148
Innodb_buffer_pool_bytes_data => 2424832
Innodb_buffer_pool_pages_dirty => 0
Innodb_buffer_pool_bytes_dirty => 0
Innodb_buffer_pool_pages_flushed => 1
Innodb_buffer_pool_pages_free => 8043
Innodb_buffer_pool_pages_misc => 0
Innodb_buffer_pool_pages_total => 8191
Innodb_buffer_pool_read_ahead_rnd => 0
Innodb_buffer_pool_read_ahead => 0
Innodb_buffer_pool_read_ahead_evicted => 0
Innodb_buffer_pool_read_requests => 512
Innodb_buffer_pool_reads => 149
Innodb_buffer_pool_wait_free => 0
Innodb_buffer_pool_write_requests => 1
Innodb_data_fsyncs => 5
Innodb_data_pending_fsyncs => 0
Innodb_data_pending_reads => 0
Innodb_data_pending_writes => 0
Innodb_data_read => 2510848
Innodb_data_reads => 159
Innodb_data_writes => 5
Innodb_data_written => 34304
Innodb_dblwr_pages_written => 1
Innodb_dblwr_writes => 1
Innodb_have_atomic_builtins => ON
Innodb_log_waits => 0
Innodb_log_write_requests => 0
Innodb_log_writes => 1
Innodb_os_log_fsyncs => 3
Innodb_os_log_pending_fsyncs => 0
Innodb_os_log_pending_writes => 0
Innodb_os_log_written => 512
Innodb_page_size => 16384
Innodb_pages_created => 0
Innodb_pages_read => 148
Innodb_pages_written => 1
Innodb_row_lock_current_waits => 0
Innodb_row_lock_time => 0
Innodb_row_lock_time_avg => 0
Innodb_row_lock_time_max => 0
Innodb_row_lock_waits => 0
Innodb_rows_deleted => 0
Innodb_rows_inserted => 0
Innodb_rows_read => 0
Innodb_rows_updated => 0
Innodb_num_open_files => 3
Innodb_truncated_status_writes => 0
Innodb_available_undo_logs => 128
Key_blocks_not_flushed => 0
Key_blocks_unused => 837
Key_blocks_used => 0
Key_read_requests => 0
Key_reads => 0
Key_write_requests => 0
Key_writes => 0
Last_query_cost => 0.000000
Last_query_partial_plans => 0
Max_used_connections => 2
Not_flushed_delayed_rows => 0
Open_files => 7
Open_streams => 0
Open_table_definitions => 67
Open_tables => 32
Opened_files => 224
Opened_table_definitions => 0
Opened_tables => 0
Performance_schema_accounts_lost => 0
Performance_schema_cond_classes_lost => 33
Performance_schema_cond_instances_lost => 0
Performance_schema_digest_lost => 0
Performance_schema_file_classes_lost => 36
Performance_schema_file_handles_lost => 1
Performance_schema_file_instances_lost => 0
Performance_schema_hosts_lost => 0
Performance_schema_locker_lost => 0
Performance_schema_mutex_classes_lost => 145
Performance_schema_mutex_instances_lost => 0
Performance_schema_rwlock_classes_lost => 20
Performance_schema_rwlock_instances_lost => 0
Performance_schema_session_connect_attrs_lost => 0
Performance_schema_socket_classes_lost => 0
Performance_schema_socket_instances_lost => 0
Performance_schema_stage_classes_lost => 0
Performance_schema_statement_classes_lost => 0
Performance_schema_table_handles_lost => 0
Performance_schema_table_instances_lost => 109
Performance_schema_thread_classes_lost => 9
Performance_schema_thread_instances_lost => 0
Performance_schema_users_lost => 0
Prepared_stmt_count => 0
Qcache_free_blocks => 1
Qcache_free_memory => 262125976
Qcache_hits => 0
Qcache_inserts => 0
Qcache_lowmem_prunes => 0
Qcache_not_cached => 62
Qcache_queries_in_cache => 0
Qcache_total_blocks => 1
Queries => 578
Questions => 2
Select_full_join => 0
Select_full_range_join => 0
Select_range => 0
Select_range_check => 0
Select_scan => 0
Slave_heartbeat_period =>
Slave_last_heartbeat =>
Slave_open_temp_tables => 0
Slave_received_heartbeats =>
Slave_retried_transactions =>
Slave_running => OFF
Slow_launch_threads => 0
Slow_queries => 0
Sort_merge_passes => 0
Sort_range => 0
Sort_rows => 0
Sort_scan => 0
Ssl_accept_renegotiates => 0
Ssl_accepts => 0
Ssl_callback_cache_hits => 0
Ssl_cipher =>
Ssl_cipher_list =>
Ssl_client_connects => 0
Ssl_connect_renegotiates => 0
Ssl_ctx_verify_depth => 0
Ssl_ctx_verify_mode => 0
Ssl_default_timeout => 0
Ssl_finished_accepts => 0
Ssl_finished_connects => 0
Ssl_server_not_after =>
Ssl_server_not_before =>
Ssl_session_cache_hits => 0
Ssl_session_cache_misses => 0
Ssl_session_cache_mode => NONE
Ssl_session_cache_overflows => 0
Ssl_session_cache_size => 0
Ssl_session_cache_timeouts => 0
Ssl_sessions_reused => 0
Ssl_used_session_cache_entries => 0
Ssl_verify_depth => 0
Ssl_verify_mode => 0
Ssl_version =>
Table_locks_immediate => 177
Table_locks_waited => 0
Table_open_cache_hits => 0
Table_open_cache_misses => 0
Table_open_cache_overflows => 0
Tc_log_max_pages_used => 0
Tc_log_page_size => 0
Tc_log_page_waits => 0
Threads_cached => 1
Threads_connected => 1
Threads_created => 2
Threads_running => 1
Uptime => 1524
Uptime_since_flush_status => 1524

Ce qui est bizarre c’est justement le fait que sur le SQL privé j'ai le même soucis alors que j'ai juste une BDD sans table et sans données. Donc a priori ca ne vient pas de ma BDD et sa structure.

Je suis complètement largué !

Je continu mon investigation mais je reste ouvert aux idées/pistes.

**J'ai fait un autre test :**

- j'ai créé une bdd sur Sql mutualisé (en mysql 5.6). Cette bdd est vide sans table ni donnée
- j'ai créé un simple script php qui fait uniquement une connexion à la bdd

**Résultat :**
- j'observe aussi des çonnexions à la bdd qui peuvent mettre 200 à 800ms le plus souvent lorsqu'on se connecte pour la première fois ou que je recharge la page après plusieurs minutes.
Ce n'est pas systématique et même si le probleme ici parait moins fréquent il semble également là.

J'imagine qu'avec ce test je peux déjà en déduire que ça ne vient pas de ma bdd (structure, index, nombre d'enregitsrements...) ni de mon code source php (framework personnel, je n'utilise aucun cms ou framework tiers).

Donc soit j'ai un soucis avec le tout petit bout de code php qui me sert à me connecter, soit je penche de plus en plus sur des soucis serveurs ... A moins qu'un truc m'échappe...

Si vous avez une hypothèse à emettre suite à ce test je suis prenneur. 🙂

Ca me rend dingue.

J'avais contacté en mars le support (ticket 6900860786) qui m'a répondu 2-3 semaines après, et malgré tous les éléments que j'ai donné ils me répondent qu'ils ne voient aucune anomalie sur leurs serveurs et que c'est certainement lié au mutualisé (idem pour le SQL privé).
D'autant plus dingue que je vois dans les logs qu'ils ont constaté le problème !

J'ai même transmis de quoi testé sur un BDD de test (vide) avec un simple script qui se connecte uniquement à la bdd.

Donc pour eux ils trouvent ca normal d'avoir sur 300v/j plus de 60-70 fois des temps de connexions qui mettent entre 200ms et 1s ! Sur du mutualisé et même sur du SQL privé ! Et ceci toute la journée (ce n’est même pas par pic !)

Il me semble que de passer sur Gravelines (moins vieillissant que Paris) et sur une version plus récente de MySql aurait dû améliorer les performances, pas fortement les réduire ???

Et bien sur ils ajoutent : prend un VPS ou un dédié ! Pour des sites de 300 V/jour avec des bdd de 4-5 Mo... logique et surtout pour un problème qui ne devrait pas existé même sur du mutualisé.
Et honnêtement si c’est pour changer d'hébergement autant changer d'hébergeur ça serait plus judicieux.

@vcasse, @AntoineB1 ou un autre membre du staff si vous pouviez passer par là pour jeter un œil à mon ticket SVP : ticket 6900860786
Je ne sais pas comment me faire entendre sur OVH. :/

Bonjour @Saxgard,

J'ai pris ton script de test (légèrement modifié, pour qu'il m'affiche le temps à chaque appel), et je l'ai mis sur mon hébergement WebHosting (à Gravelines également). J'ai appelé le script toutes les secondes pendant 20 minutes (entre ~12:02 et ~12:20), et voici mes résultats:

- 4ms de moyenne

Sur les 1156 appels, j'en ai eu 4 (0.35%) à plus de 0.1s:

- 0.11s
- 0.90s
- 0.10s
- 0.81s

J'ai l'impression que ton ressenti est bien différent. Tu me confirmes qu'on ne parle pas du tout des même ratios? Est-ce que tu pourrais mettre le script de test sur ton hébergement, et m'envoyer l'URL en message privé?

Mikaël

Bonjour

Dans mon ticket je précise bien qu'il est inutile de tester toutes les secondes. Ces temps de connexions élevés semblent nettement plus fréquents à la première connexion d'un visiteur ou si on reste au moins un certains temps (au moins 1 minutes peut être un peu plus ou un peu moins) avant de recharger la page.
Et c’est pour ça que sur environ 300-400 visites/jour (en ajoutant quelques visites de bots tels que Googlebot) j'ai environ une soixantaine d'enregistrement dans mes logs concernant un temps élevé pour la connexion. Ce qui n'est effectivement pas le même ratio.

Tout est bien précisé dans mon ticket. Donc ce test n'est évidemment pas significatif.

Je ne comprend pas, le script de test fourni sur mon hébergement affiche bien le temps de connexion à chaque appel. Je vois ça en MP avec toi.

PS : merci de t'intéresser à mon cas. :)

Je vais tenter de résumer ici ces derniers jours de tests et de messages privés.

Comme un graph vaut mieux qu'un long discours, voici un résumé de la situation en image:

Il s'agit du temps de réponse d'un script (PHP) de test qui ne fait rien d'autre qu'une connexion à une base. Le temps de connexion est évalué par le script PHP lui même. En gros:

$start = microtime(true);
$db = new PDO(…);
$end = microtime(true);

Dans cet exemple, le test est lancé toutes les 10 minutes. Sur 144 appels, 21 mettent environ 0.8 seconde, les autres quelques ms. Ça fait environ 15% d'appels avec un temps de réponse peu acceptable.

Si on augmente le nombre de calls (ex: 1 par seconde), le nombre d'appels avec lenteur reste globalement le même, et donc le % chute. Bref, le problème est peu visible sur les sites très sollicités, il l'est beaucoup plus sur les sites moins appelés.

(Très) important:

* Le problème a été reproduit sur mon hébergement (offre différente, perf vs perso, cluster web différent…)
* Le problème a été reproduit sur un autre SharedSQL, et sur un CloudDB WebHosting (PrivateSQL).
* Le problème n'est **pas** reproduit si on remplace le nom (xxx.mysql.db) par l'IP. Un test de 236 appels, même conditions (toutes les 10 minutes…) montre que les délais sont compris entre 2 et 4 ms:



Je passe la main à la team WebHosting qui va regarder du côté des DNS.

À dispo,

Mikaël

Merci beaucoup pour le travail effectué. Le problème est enfin détecté par OVH et c’est un soulagement.
Reste plus qu'à attendre qu'il soit corrigé. ^^

Bon bin des mois plus tard, problème toujours pas réglé !!

@vcasse , @MikaelD1 ne pouvant plus faire le suivi (vacances et changement de lieu de travail) j'aimerais savoir si vous pouviez faire quelque chose pour que le service webhosting corrige enfin ce problème qui d'après les tests de MichaelD1 affecte la plupart des mutualisés (SQL privé ou non). Voir son analyse plus haut et les retours qu'il avait pu faire au service Webhosting.
C’est lui qui m'a conseillé de vous relancer si le problème n'était toujours pas corrigé.

Merci d'avance.

PS : c'est ma dernière relance, après j'abandonne !

Bonjour @Saxgard,

Mes collégues sont toujours à la recherche de la cause de ces lenteurs. Je reboucle avec eux et je te tiens au courant

Cordialement,
Vincent

Bonsoir

Super merci
Content de savoir que vous êtes toujours sur le coup ^^

Bonjour @Saxgard,

Nous déployons actuellement un correctif qui améliore la résolution DNS des nom d'hôtes des bases de données, et c'est déjà effectif sur le cluster 005.
J'apporterai plus de détails sur ce qui a été corrigé une fois le déploiement terminé

Tarik

Le déploiement du correctif est en arrêt pour le moment, nous proposerons une version améliorée les jours à venir

@TarikM2 je vous remercies **mais** je viens de vérifier sur le cluster 005 (cluster où le correctif aurait été appliqué) et **je ne vois aucune amélioration**. J'ai vérifié sur les 10 derniers jours dans mes logs.

Effectivement, le correctif en question a été retiré pour l'instant.
La nouvelle version sera disponible dans 2 semaines :)

D'accord merci ^^ j'attends donc votre retour lorsque la nouvelle version sera mise en place.

Salut @Saxgard, c'est déployé à nouveau !
Désolé pour le temps que ça prend, mais il fallait attendre la migration complète de P19

Bonjour

Merci @TarikM2 , effectivement tout semble enfin ok au niveau des connexions depuis le 24 octobre environ.

Bonjour à tous
Je ne suis pas un spécialiste, loin de la.
Il y a une chose qui sauf erreur de ma part, peut modifier le temps de chargement d'un site, il s'agit du "Cron".
En effet les tâches planifiées sont étalées de 1 minutes à plusieurs heures.
Chaque tâche se lance donc lorsque le compteur horaire arrive à son terme.
Ce "Cron" se lance à chaque fois qu'un visiteur se connecte au site.
Donc si le temps est long entre chaque visiteur, le chargement de toutes les tâches planifiées non exécutées entre le temps de la dernière visite et celle qui est en cours peut être plus ou moins long.
Je sais que le "Cron" se trouve chez l'hébergeur et qu'il est modifiable.
Les tâches planifiées viennent de divers plugins, mais surtout des mises à jour obligatoires.
Ceci est une idée et je le répète, je ne suis absolument pas un spécialiste.
Je ne pourrais donc aider sur ce sujet.
Pour "kyodev", je n'ai toujours pas réglé mon PMA. Je n'aurais vraiment pas d'autre choix que de voir avec le support.
Bonne journée à vous.

tu parles de Worpdress qui n'est pas le sujet ici... mais PAS DU TOUT
en mélangeant quelques vérités avec des affirmations erronées
quand au reste désolé, si tu n'interviens pas sur TON sujet, je n'ai pas ton problème en tête

Bonjour @MichelD35,
Le souci remonté ici est générique à l'ensemble des sites web utilisant une base de données avec la convention de nommage : dbname.mysql.db et dbname.privatesql , et concernait l'initialisation du cache DNS sur le serveur web qui traite la requête, qui maintenant est beaucoup plus rapide. (oui encore du cache @kyodev)
Pour les crons qu'OVH propose à ses clients (et pas les crons WP ou autre), ils fonctionnent différemment et sont exécutés même si le site n'a pas de visites, donc ce n'était pas un facteur ici.

Merci à vous pour ces informations.
Je n'avais que formulé une idée qui n'était pas dans le contexte du sujet, je l'admet.
Quelquefois, cela m'est arrivé plusieurs fois dans ma carrière, une personne débarque avec une idée qui peut parraitre hors sujet, peut amener à une autre solution que personne n'aurait pu envisager.
J'ai essayé et je me suis planté.
Bonne journée à vous
Michel