Bonjour,
J'ai un site ecommerce avec du code fait à la main (je suis dev web donc pas débutant non plus) en mutualisé OVH
Depuis juillet j'ai noté une baisse très très importante de trafic sur mon site, mon SEO qui était très bien depuis 8 ans est devenu très mauvais depuis mi aout sans raisons ni changement particulier,
Certaines de mes pages sont lentes à charger (surtout l'espace client, les pages de statistiques sur le backoffice, ...), et le nombre d'inscription a drastiquement chuté.
Depuis des semaines j'essaye de trouver la raison et je viens de voir que mysql était passé à la version 8.0, se pourrait-il qu'il y ai un lien svp?
Je suis un peu perdu, c'est mon revenu principal, je gagnais un bon salaire avec ce site et en deux mois je suis passé à des revenus très justes alors que c'était excellent pendant 8 ans sans la moindre coupure ou baisse,
Merci pour votre lumières
Hébergement Web-old - Mysql 8 sur mutualisé: Grosse chute de SEO, de CA et de visites + lenteurs importantes
Related questions
- [RESOLU] Server unable to read htaccess file, denying access to be safe
74584 
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
68993 10.01.2019 11:14
- Effacer wordpress d'OVH et reinstaller
68461 08.09.2019 21:02
- Comment récupérer son mot de passe phpmyadmin ?
67653 14.11.2016 10:32
- Ne supporte pas FTP sur TLS
65216 11.12.2018 18:48
- Changer la version d'une base de donnée en mutualisé
65025 22.12.2016 11:46
- Résiliation hébergement
64944 27.07.2018 10:39
- Variable upload_max_filesize plus grande que post_max_size
57342 11.06.2017 16:01
- Résiliation hébergement+domaine
56698 11.09.2018 20:28
- Transfert hebergement et domaine .fr entre client OVH ?
54977 21.12.2016 15:10
Bonjour,
Sans pouvoir faire une corrélation entre Mysql8 et votre baisse de revenus, quelle est l'adresse de votre site ?
Bonjour,
Il y a certainement un lien, j'ai été confronté au même constat en début de ce mois (dès l'upgrade en MySql8). Le temps de réponse de Mysql est complétement parti en cacahuète (pour la même requête en 5.7 le temps mesuré était de 0.003, en 8 il est passé à 1.331...).
Il va falloir mettre les mains dans le cambouis afin d'optimiser les requêtes qui alourdissent le site.
Pour ma part, c'est rentré dans l'ordre mais je dois avouer une légère baisse des performance vs 5.7.
Je vous conseille de vous activer à résoudre ce problème, car le CLS du web core vital va en prendre un coup...
Pour vous faire gagner du temps si vous envisager de contacter le support : Inutile de vous rapprocher du support OVH, la réponse sera : "Pas de problème constaté sur nos infrastructures".
Bonjour, même constat chez moi et je comprends que avant mysql 8, un cache automatique côté bdd permettait d'obtenir de très bons temps d'exécution SQL à partir de la 2ème exécution d'une même requête. Avec mysql 8 le cache semble ne plus exister avec des temps d'exécution SQL qui restent constants.
Bonjour je vous ai envoyé un mp avec le site web en question
Bonjour est-ce que votre référencement a aussi drastiquement chuté? En deux mois j'étais en deuxième position sur beaucoup de mots clés ce qui m'assurait 20-30 inscriptions par jours, maintenant sur ces mêmes mots clés je suis en 5ème page google (donc inutile) et je tourne à 0-5 inscriptions par jours sur mon site web, c'est dramatique
Bonjour
Même constat niveau référencement et trafic ou juste lenteurs ?
Bonjour,
En naviguant sur votre site, je n'ai pas décelé de lenteurs.
Bon succès quand même.
Bonjour,
Non, je suis d'assez près mes métriques et j'ai pu intervenir avant la catastrophe...
Revoyez impérativement votre code (requêtes), les moteurs de recherches ne vous ferons pas de cadeaux si vos pages mettent 10 secondes a s'afficher...
Si c'est une source de revenus pour vous, ce problème doit passer en haute priorité dans votre agenda.
Bonjour, non aucun impact négatif sur le référencement. Ceci dit, la suppression du cache SQL que j'ai observé n'affecte pas vraiment la performance d'affichage du site car par exemple je gère un système de cache HTML.
J'utilise très peu les index en mysql car j'avoue que j'ai toujours eu beaucoup de mal à comprendre et les choisir,
Je pense qu'en utiliser rendrait mes requêtes SQL bien plus rapides (suite à ce thread j'en ai essayée sur phpmyadmin et elles retournent 3 secondes ce qui est énorme)
Savez vous comment je peux organiser ma DB et crééer des index sans me planter ?
Exemple :
SELECT c.CategoryName, c.CategoryColorClass, c.CategorySlug, c.CategoryColor, c.CategoryIcon, p.*, COUNT(o.OrderID) as nb_total FROM orders o INNER JOIN products p on o.OrderProductID = p.ProductID INNER JOIN categories c on c.CategoryID = p.ProductCategoryID WHERE p.deleted = 0 GROUP BY o.OrderProductID ORDER BY nb_total DESC LIMIT 10
Cette requêtes est super longue tout ça pour ressortir 10 produits ...
Je vois tout de suite des candidats pour être indexés:
OrderProductID
ProductID
CategoryID
ProductCategoryID
en fait tout ce qui a un ID (typiquement un numéro unique) est candidat à être indexé sur cet ID.
ils ont déjà tous un index Primary sur leur propre table (ProductCategoryID -> CategoryID sur la table Category, OrderProductID -> ProductID sur la table Product, ect...) pourtant
J'ai trouvé un petit cours/tuto
https://sqlpro.developpez.com/cours/quoi-indexer/
Comme il y a des GROUP BY, des INNER JOIN, et COUNT dans ton ordre SQL il faut tenter de bien comprendre comment mysql va procéder sans devoir lire séquentiellement toute une table autant de fois qu'il y a des lignes dans les 2 autres tables (le produit des deux)
Envisager LEFT JOIN selon le cas d'espèce. Ca peut aussi changer le temps de réponse et il faut s'assurer si le LEFT JOIN donne le même résultat dans ton cas.
Il faut également faire des index avec plusieurs champs...
Une des méthode est de mettre le site sur le poste de travail (ou un serveur de dev) et de configurer Mysql pour qu'il log les requêtes sans index puis, de corriger.
Bon courage.
Je vais jeter un oeil merci