Est-ce que vous avez déjà regardé l’état de votre base de donnés MySQL Prestashop ? Bien souvent on ne pense pas à regarder en détail… pourtant celle-ci peut devenir lente et arriver à saturation.
Base de données saturée de statistiques
Combien de fois je vois ça… des bases de données Prestashop qui sont gonflées à bloc à cause des statistiques…. parfois 80% de la taille de la base de données concerne les statistiques. Est-ce que ces informations sont importantes ? Dans le 99% des cas non, car ces informations font doublons avec les statistiques de Google Analytics.
Je ne peux pas vous affirmer avec certitude qu’un Prestashop avec de grosses tables de statistiques serait plus lent qu’un autre qui lui aurait ces tables mais vides… Par contre, le fait d’avoir une grosse base cause problème aussi pour les backup, ça prend du temps… ou même pour transférer la base de données vers un autre serveur c’est très long et lourd… du coup autant faire le nettoyage.
Sincèrement je pense que l’option des statistiques de Prestashop devrait être désactivé par défaut, la plupart des sites e-commerce sous Prestashop ont des bases MySQL énorme et stockent des informations qui ne sont pas utilisées. Mais il y’a pire encore parfois cela fait saturer l’hébergeur en terme de volume (encore + de risque si vous avez un hébergement pas cher).
Cela fait déjà un moment que j’avais parlé de la méthode faire un Prestashop léger pour les backup… mais cela était resté en mode exécution manuelle sur la base MySQL. Maintenant avec le processus que je vous propose, votre boutique fera du fitness tous les jours et ne prendra plus de « Kg » inutiles 😉 .
Ressources
Pour ce tutoriel vous avez à disposition :
- Un fichier d’override « indexController.php »
Réduire sa base de données
- La problématique du poids de la base de données est un problème récurrent. Arrêtez de stocker du contenu inutile que vous ne consultez même pas.
- Mettons en place un système d’override qui videra automatiquement les tables de statistiques à chaque fois que la page d’accueil est chargée.
- N’oubliez pas de supprimer le fichier « app\cache\prod\class_index.php » ou « app\cache\dev\class_index.php », pour que l’override soit bien pris en compte.
- Comparez l’état des tables avant / après opération, cela doit être le jour et la nuit… logiquement les tables citées devraient être vides.
- Est-ce que cette manipulation présente des risques ? Non, car les statistiques qui sont remontées, ne sont pas réellement utile pour le marchand… il pourra les trouver aussi via Google Analytics.
- Il n’est jamais bon d’avoir une « grosse » base de données, cela entraîne parfois des ralentissements, voir même saturation de l’espace chez l’hébergeur.
- Peut-être un module à faire ? Qui sait ?
Bonjour Germain,
Je vais bientôt passer de la version PS 1.5.4 à la version PS 1.7.2.2, et cela grâce à tes nombreux conseils et vidéos. Bravo pour toute ton oeuvre!!
Avant de faire la mise à jour, je voudrais alléger ma base de données, mais je voudrais être certain de pouvoir vider les tables ci-dessous. D’après toi, puis-je les vider?
bs_pm_cachemanager_cache_content = 98M
bs_statssearch = 78M
bs_pm_cachemanager_cache = 58M
bs_pagenotfound = 15M
En te remerciant vivement,
Bruno
Hello,
Je ne connais pas forcément toutes les tables, mais j’aurai envie de dire ceci :
bs_pm_cachemanager_cache_content = NON
bs_statssearch = OUI (si tu n’utilises pas les statistiques de recherche)
bs_pm_cachemanager_cache = NON
bs_pagenotfound = OUI
Dans tous les cas, il faut procéder à un backup avant de réaliser ce type d’opération.
A bientôt !
Bonjour
merci pour vos vidéo qui m’ont était très précieuses
avec prest 1.7.2 en essayant d’afficher les produits dans une certaines sous catégorie je les retrouve partout dans les autres catégorie donc afin de remédier à ce problème j’ai pensé à créer une nouvelle requête qui me récupère les produits mais je ne sais pas où la modifier au niveau de mes fichiers
merci pour votre aide
Bonjour,
Désolé, mais votre question est trop spécifique / technique pour je puisse y répondre ici.
A bientôt !
Bonjour Germain,
Merci pour tout ces bons conseils.
La prise de poids des Bdd prestashop est un problème récurrent… je travaille à la migration de ma boutique vers un PS1.7, c’est qqchose qui me préoccupe.
Je garde bien au chaud votre override très instructif, cependant ne serait-il pas judicieux, avec votre expertise, de donner la liste des modules PS1.7 à « Désactiver » pour ne plus avoir ces tonnes des données générées (gain temps de traitement) et stockées (gain taille Bdd).
En PS1.4 j’avais réussi a « stopper » les modules, que je jugeais inutiles remplacé par google analytics et pour des choses plus locale/perso, ex « meilleur client de l’année »,je me débrouillait avec des requêtes en base), mais je n’ai pas cette expérience/expertise en PS1.7…
Peut être une idée pour un prochain billet « Prestashop 1.7 » ?
Merci.
A bientôt.
Hello,
Disons que du côté de la base de données, c’est vraiment ces tables qui font grossir la base et ce processus permet vraiment à la base de données de rester « light ». Pour les modules à désactiver je note surtout 1 module important le « merchant expertise » qui ralenti le back-office Prestashop (à désactiver absolument).
A bientôt !
Ce qui est bien c’est que quand on cherche comment faire un truc sur Prestashop, on tombe presque toujours ici 🙂
Merci pour ce petit tuto bien utile encore une fois.
Pour ce qui est du fichier class_index.php, il semble qu’il ait encore changé de place. Sur une 1.7.4.2 je l’ai trouvé dans /var/cache/prod.
Hello,
Ahaha il y’a quand même d’autres blogs aussi qui traitent de Prestashop 😉 Le dossier parent « /prod » ou « /dev » peut être en principe supprimé en cas de besoin (Prestashop le recrée automatiquement).
Merci pour l’info !
Merci beaucoup Cyrille, je ne le trouvais pas!
Bonne journée
Bonjour Germain, comme a ton habitude tu traites des sujets utiles, dans mon cas ma BDD fait 250Mo et le total des tables Connection + Gest est de 195Mo !!!, je souhaiterais donc les vider mais pas totalement, est il possible de mentionner un nombre de jours dans un Override et si oui comment le faire, j’aimerais conserver les 3 derniers mois (ou 90 jours) merci pour ton aide précieuse a la communauté prestashop.
Hello,
Pour cela il faudrait ajuster un peu la requêtes SQL du controller en ajoutant une règle sur la colonne « date_add » pour la suppression… mais j’ai pas ça en tête. Il faudrait regarder du côté SQL pour les dates ou « date between ».
A bientôt !
Bon, encore un tuto Webbax appliqué avec succès. Magnifique, j’ai divisé par 4 la taille de ma BD hébergée chez OVH. Hasard du calendrier, au même moment (à quelques jours près) l’hébergeur a effectué une migration de serveur. Résultat : vitesse record (j’ai pas bien vu en Front Office, en fait j’ai pas fait les tests, mais en Back Office la vitesse est enfin confortable, ces dernières semaines çà ramait vraiment beaucoup trop).
Donc merci Webbax, toujours au top, et conseil aux autres lecteurs : foncez sur ce tuto, c’est du tout bon.
Bonus, retour d’expérience après une semaine : y a un plus supplémentaire : le fait de vider les stats de Prestashop fait qu’évidemment on ne peut plus les lire (mais Google Analytics est notre ami) et donc on ne perd plus de temps à essayer de les lire (c’était une mauvaise habitude que j’avais prise et qui vient de me quitter). çà fait toujours de précieuses minutes gagnées…
Bonjour,
C’est une bonne nouvelle si cela a optimisé la vitesse. Regardez aussi pour supprimer le module « Gamification » ou « Merchant Expertise », celui-ci peut être la cause de ralentissement.
A bientôt !
Bonjour,
Sur un hébergement de 25GB, le cpanel m’affiche en occupation Mysql 19Gb au moment où le public_html fait que 2.5Gb. Le phpmyadmin affiche 8Gb.
Comment gérer cela?
Merci de m’aider car ceci explose mon pack hébergement
Bonjour,
Pour cela je vous conseille peut-être de contacter votre hébergeur afin de faire une analyse avec lui pour diagnostiquer les emplacements « volumineux ». Pensez à purger les 4 tables suivantes de Prestashop afin d’alléger votre base de données : https://www.webbax.ch/2014/01/15/un-prestashop-leger-pour-les-backup/
A bientôt !
Tutoriel bien utile, cependant les commandes passées n’ont pas été enregistrées (j’ai eu cependant les notification de paiement par la banque) et les nouveaux client ont été enregistrés, j’ai du donc contacter les clients pour connaître leurs produits commandés. J’ai donc supprimé le fichier IndexController.php V 1.7.6.9.
Bonne continuation et continue a nous former .
Continue à prendre soin de toi et de tes proches .
Salut !
De mon côté content de pas avoir supprimé les stats Prestashop !
C’est une mine d’or à exploiter pour son business
Notamment les stars des ventes produits meilleures ventes etc
Avec la possibilité de pouvoir avoir des données sur un certain nombre de temps et choisir ses dates faire des comparatifs …
J’aurai jamais des stats comme ça avec Google analytics
Ça me permet de bien comprendre ce qui se passe
…
Hello,
Pour information cela supprime les statistiques liées au trafic et à la navigation (pour cette partie Google Analytics fait mieux que PrestaShop). Les statistiques internes liées aux ventes restent intactes.
À bientôt !
Hello,
Merci pour ces informations très utiles !
Je me suis servi de tes requêtes SQL pour préparer plutôt des events sur PhpMyAdmin. Ca revient quasiment à la même chose, mais comme j’avais déjà d’autres events sql, j’ai préféré en rajouter d’autres.
Au cas où ca vous intéresserait, ci-dessous le sql pour créer un event :
CREATE DEFINER=`root`@`localhost` EVENT `Nettoyage tables traffic ps_guest` ON SCHEDULE EVERY 1 MONTH STARTS ‘2023-01-01 08:58:39’ ENDS ‘2033-03-31 08:58:39’ ON COMPLETION PRESERVE ENABLE COMMENT ‘Nettoyage de table de traffic prestashop’ DO TRUNCATE TABLE ps_guest;