Bonjour,
Nous hébergeons un site e-commerce sous Prestashop.
Nous avons créer une application web dédié à l'usage unique de nos collaborateurs qui utilisent la même base de données SQL que celle du Prestashop.
Cette application permet de modifier des informations telles que les prix des produits par exemple.
Sur le papier, tout fonctionne très bien. Néanmoins, la connexion de cette application (hébergée en local dans nos locaux) à la BDD en utilisant PDO est extrêmement lente. J'étudie en ce moment même une solution qui me permet d'avoir un dump de la BDD en local pour l'application en faisant une mise à jour des informations une fois par jour vers la la BDD.
Mais cette "solution" ne nous convient pas, nous aimerions savoir comment améliorer le temps de connexion à la BDD.
Toute aide sera la bienvenue, merci beaucoup.
La connexion (PDO classique) :
```try {
$cxn1 = new PDO('mysql:host=' . $dbHost . ';dbname=' . $dbName1, $dbUser, $dbPass);
$cxn1->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
}
catch (PDOException $e) {
echo 'Error: ' . $e->getMessage();
}```
-Version PHP globale 7.1
-Offre perf2014x2
-MySQL 5.7
MySQL connexion avec PHP très lente
Sujets apparentés
- Lien database non établi
6966 
06.12.2016 11:04
- "Connection timed out" - Connection MySQL privée via PHP
6908 13.02.2018 00:37
- Autoriser toutes les IP
5050 11.08.2018 19:16
- Help, Base de donnée pleine, supprimer product ID phpmyadmin
4938 12.06.2019 14:05
- Intégration de MongoDB
4918 12.10.2016 09:01
- Comment passer de MySQL 5.6 à MySQL 8.0 ?
4484 12.06.2019 15:49
- Connexion à base de données en utilisant ODBC
4401 04.09.2018 11:57
- Les connexions simultanées
4221 24.10.2019 13:23
- Exporter la base de données avec un script PHP
3962 05.10.2018 11:27
- [1034] Create index by sort failed
3529 06.03.2020 09:31
Bonjour @FrancoisC73
Si j'ai bien compris, vous souhaitez qu'une application en local sur votre PC puisse interroger, modifier le contenu d'une base de données sur un hébergement mutualisé.
Si c'est la base de données livrée avec l'abonnement mutualisé : **c'est impossible.**
_Et heureusement pour des raisons de sécurité._
Il doivent plutôt avoir avoir un dédié ou un VPS car il semble dire que cela fonctionne mais que c'est lent.
Bonjour,
Le code fournit est une connexion standard à une BDD avec pdo.
Cela ne permet pas du tout de savoir pourquoi vos requêtes sont lentes.
Pouvez vous déjà nous dire sur quoi vous êtes hébergé ?
Dans l'immense majorité des cas pour votre soucis, le problème provient des requêtes BDD mal fichues ou d'index manquants.
Merci pour votre réponse.
Effectivement le CRUD de l'application locale fonctionne très bien et les données sont bien modifiées sur la BDD OVH cloud. Le chargement des données est trés lent oui.
Le code PDO fournis est effectivement une connexion classique.
Voici les requêtes, à titre informatif, permmetant de charger la page d'accueil de l'application :
En ce qui concerne mon abonnement comme indiqué sur les factures :
-Hébergement Web - Performance2 - 12 mois
-Serveur sql privé 1Go de RAM - 6 mois
Je suis rentré dans la société après la souscription du contrat. Je ne sais pas comment trouver d'autre informations, si vous pouvez m'indiquer.
Je sais que c'est un abonnement mutualisé d'aprés ce qu'on m'a dit. Si je bénéficié d'un VPS, cela serais visible sur mes factures non ?
Merci encore.
Je suppose que c'est cette base de données que vous utilisez.
Oui bien sûr c'est celle ci
Je laisse la place aux spécialistes.
Je n'utilise pas les offres mutu, @Gaston_Phone sais tu si les sql privés permettent une connexion extérieure ? Ou alors peut être qu'il est possible d'avoir du VPN sur ces hosts ?
Merci pour les exemples des requêtes, les jointures me paraissent bonnes. Les conditions sont sur des id ça devrait le faire.
Reste à vérifier le bon indexage des colonnes mais comme ce sont des tables de prestashop, ça devrait à priori.
Pour le savoir il faudrait, sur votre SQL privé, activer la journalisation des :
- requêtes lentes (supérieures à 1, voir 2 secondes).
- requêtes sans index
Vous pourrez ainsi avoir sans effort un premier diagnostique (BDD ? , processeur ? réseaux ? le site internet à trop de visiteurs ? )
>Je sais que c'est un abonnement mutualisé d'aprés ce qu'on m'a dit. Si je bénéficié d'un VPS, cela serais visible sur mes factures non ?
Les VPS (à puissance égales sont bien plus cher que les serveurs dédiés).
Compter dans les 80€ mensuel d’infogérance + le prix du serveur. Dans votre cas, comme il y a un Prestashop en plus, si vous avez un peu de traffic et de chiffre d'affaire ce n'est pas déconnant.
Oui @TTY, d'après ce que j'ai compris des discussions précédentes.
Fonctionne sur Serveur sql privé 1Go de RAM, mais très lent.
Merci pour le conseil !
Effectivement consulter les logs me semble être un excellent début.
Je n'y avais pas pensé et je ne savais que c'était possible (mais c'est logique en fait).
Par contre, je suis embêté :
Quand je vais consulter l'onglet "logs" dans mon SQL privé tout est vide. Vous m'avez dit de les activer, je n'ai pas trouvé comment faire.
J'ai suivi la documentation officielle d'OVH pour les consulter -> https://docs.ovh.com/fr/clouddb/debuter-avec-clouddb/#recuperer-les-logs-de-votre-serveur-clouddb doc
La documentation ne parle aucunement d'activation.
J'ai donc essayé naturellement de me connecter à la BDD en SMTP avec Filezilla pour récupérer ```stdout.log``` mais sans succès : ```"Erreur: Connection interrompue après 20 secondes d’inactivité"```
(J'ai bien vérifier mon mot de passe et choisis le protocol SMTP dans Filezilla)
Merci @TTY et @Gaston_Phone pour votre temps et vos conseils.
Bonjour,
Au dernière nouvelles : non
Il faut une CloudDB et mettre son IP en autoriser.
@FrancoisC73 : c'est quoi l'hôte de vôtre BDD ?
Si vous faites un ping vous avez quoi comme latence ?
Car avant de chercher un problème dans les requêtes faut commencer par la base : le temps initial entre l'application local et le SQL distant.
Cordialement, janus57
Je ne connais pas les SQL privé. Les services Mysql est configuré via un fichier my.cnf . Voyez la documentation OVH.
Suite à l'intervention, de @janus57 qui nous dit que votre BDD ne devrait pas être accessible depuis l'extérieur ce vous vous décrivez comme fonctionnement n'est peut être pas exact. Difficile d'y voir clair.
Bonjour @FrancoisC73
**Pouvez-vous nous confirmer que, même si l'opération longue, vous arrivez bien à accéder à votre **Serveur sql privé 1Go, à y faire des opérations de lecture et d'écriture ?**
_C'est très important de savoir pour le reste de la discussion._
Oui absolument je confirme lecture, écriture.
Je suis bien en CloudDB et mis mon IP en autoriser.
CloudDB = SQL privé ?
Bonjour,
Je suis en cloudDB et mis mon ip en autorisé oui.
Host : clouddb015.eu008.
Comment je fait pour ping ma bdd exactement ?
Merci
Oui, sur mon tableau de bord le libellé de la BDD c'est "SQL Privé"
Dans votre premier message, le code de connexion.
Regardez et donnez nous la valeur de $dbHost (et uniquement celle-ci)
Je veux bien lire toute la doc du monde.
Mais laquelle ? J'ai absolument rien trouvé et j'ai mis en référence la doc que j'ai consulter pour cette histoire de logs dans les messages précédents.
1001.eu.clouddb.ovh.net001.eu.clouddb.ovh.net est le nom d'hôte de la base
Merci.
>ping 1001.eu.clouddb.ovh.net001.eu.clouddb.ovh.net
PING clouddb015.eu008.clouddb.ovh.net (141.94.24.136) 56(84) bytes of data.
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=1 ttl=44 time=17.0 ms
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=2 ttl=44 time=16.9 ms
Oui c'est bien accessible depuis le net et la latence est bonne depuis chez moi (17ms).
Faite un ping comme le suggère @janus57 depuis vos locaux et donnez nous le résultat.
Voici :
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=1 ttl=45 time=23.0 ms
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=2 ttl=45 time=21.1 ms
Merci
La connectivité semble bonne.
Je ne vais pas pouvoir vous conseiller beaucoup plus.
- Activation des log requêtes lentes et non indexés (comme vu plus haut) faite un ticket pour cela au pire.
- Vérifiez que la charge du cloudDB ne soit pas trop importante (je pense qu'il doit y avoir des graphiques pour ça dans le manager)
Si ces 2 points sont OK, alors il va falloir prendre un prestataire pour trouver ou est le "goulet" d'étranglement et résoudre votre problème.
@janus57 qu'en penses tu ?
Bonjour,
non c'est 2 services différent
CloudDB == instance SQL accessible depuis internet (si IP mis en liste verte)
SQL privé == instance SQL accessible seulement et uniquement depuis les hébergement mutualisés.
Pour le CloudDB voici la documentation : https://docs.ovh.com/fr/clouddb/configurer-optimiser-son-serveur-de-base-de-donnees/
Normalement vous avez accès à un panel de graphiques et surtout des conseils en fin de guide
Le dernier test que j'aurais fait c'est de mesurer (en PHP) le temps que PDO met à se connecter au serveur SQL puis a fermer la connexion.
Par contre pour moi le ping est "pas bon", une très bonne latence serait inférieur à 5ms, une latence "okey" serait à 20ms grand maximum, au delà ça commence à être mauvais.
Peut être que @MikaelD1 (Team OVH) pourrais jeter un coup d'oeil
Cordialement, janus57
Bonjour,
> CloudDB == instance SQL accessible depuis internet (si IP mis en liste verte)
> SQL privé == instance SQL accessible seulement et uniquement depuis les hébergement mutualisés.
Ceci était vrai il y a encore quelques mois, mais ne l'est plus maintenant ! Toutes les instances sont accessibles depuis internet, et un bouton permet de mettre en liste verte les clusters des hébergement mutualisés:
Concernant le problème de lenteurs, je constate que la RAM plafonne souvent à 100% avec certains pics qui occasionnent un OOMkill (Saturation de la RAM allouée), entraînant un redémarrage de la base toutes les 24/48 heures depuis environ une semaine, ce qui peut causer des lenteurs importantes:
1. L'application lance un traitement lourd
* L'instance sature sa RAM et redémarre
* L'application voit qu'elle perd la connexion avec la base de données
* L'instance redémarre avant que l'application ne dépasse son timeout
* L'application voit le retour de la base et relance son traitement
* Cette fois-ci le traitement passe car de la RAM a été libérée suite au redémarrage
De votre point de vue, le premier traitement a été effectué en quelques secondes au lieu de quelques millisecondes
Une autre explication possibles est la suivante: comme la RAM est entièrement allouée, le conteneur utilise une partie de sa SWAP (D'une certaine manière de la mémoire déportée sur le disque dur) qui est beaucoup plus lente lors du traitement.
Il serait judicieux de voir comment optimiser le contenu de la base de données ou les requêtes.
Si aucune amélioration de ce coté n'est possible, la solution la plus simple serait de passer sur une offre supérieure.
Bonjour,
Merci pour l’information, car il ne me semble pas avoir vu passé cette nouveauté/changement.
Du coup en faite le terme "SQL Privé" n'existe plus, maintenant ce sont des "CloudDB" qui sont fournis avec les hébergements Perf ?
Note : tout ces termes ça commence à être chiant pour s'y retrouver au niveau des produits OVH…
Cordialement, janus57
Merci pour ce retour @FabienB42
@janus57
>Par contre pour moi le ping est "pas bon", une très bonne latence serait inférieur à 5ms, une latence "okey" serait à 20ms grand maximum, au delà ça commence à être mauvais.
La vache tu es pas un peu dur ? Je n'ai jamais eu un ping inférieur à 13ms depuis mes locaux (fibré Orange Pro FTH) quelque soit le serveur (bon je suis en zone rurale dans le sud Ouest...)
>Note : tout ces termes ça commence à être chiant pour s'y retrouver au niveau des produits OVH…
+1
Bonjour,
oui et non, sur un système synchrone j'ai 2ms maximum (en tête) pour ne pas percevoir une dégradation de perf.
Du coup je prend un facteur x10 pour un système "standalone" => 20ms
je n'ai jamais eu l'idée de faire du SQL distant à travers internet, encore moins quand l'éditeur ne peut pas me certifier qu'il va utiliser du TLS.
Cordialement, janus57
Merci.
Bonjour et merci pour la réponse,
Non, l'application ne lance pas de traitement lourd du tout, ce sont de simple requête SQL toute bêtes (visible sur l'un de mes messages précédents).
Je viens de recharger la page d'accueil de l'application (toujours aussi longue) et je n'ai constaté aucun dépassement de RAM supplémentaire depuis mon tableau de bord de mon espace client.
Merci de noter que notre Prestashop, qui utilise la BDD en question, n'a aucun problème de lenteur, bien qu'il fasse des requêtes bien plus complexes et nombreuses.
Notez que l'application n'étant pas utilisable avec cette lenteur, elle n'a pas était utilisé depuis bien plus d'une semaine, elle n'est pas en cause des redémarrages.
Merci pour votre proposition de passer sur une offre supérieure, mais je veux être sûr ET garantis que cela solutionnerait le problème avant d'upgrader notre abonnement !
J'ai créé un ticket pour avoir accès au log de la BDD (Les logs n'étant pas visibles sur l'espace perso + aucun moyen de me connecter en SFTP pour récupérer stdout.log, on ne sait pas pourquoi.
Merci
Voici, merci pour le conseil
Bonjour a tous,
Je suis d'accord avec @janus57 sur le probleme de la latence, une base de données peut repondre a une requete en moins d'une miliseconde, du coup quand on rajoute 20ms a chaque requetes, ça peut vite faire exploser le temps de reponse globale. C'est pour cette raison qu'il faut toujours avoir sa base de données au plus proche de son application. (Dans ton cas si l'application etait hebergée sur le serveur du Prestashop, ça marcherai surement beaucoup mieux)
Ensuite j'ai regardé les requetes, les 3 premieres pourraient etre combinées en une seule, la 4eme te renvoit plus de 7800 lignes pour que tu ne prennes que la premiere (au hasard du coup). Difficile de diagnostiquer quelque chose avec cet "extract" des requetes :/
Il faudrait que tu arrive a timer chacune des requetes qui partent de ton serveur pour voir ce qu'il se passe vraiment, lesquels vont bien, lesquels non et identifier vraiment un probleme.
En esperant avoir repondu a quelques interrogations :)