06/01/2025 Franck Bugnet Conseil

10 façons super efficaces de stimuler votre gestion de données...

Fatigué de la lenteur de PrestaShop ? Des milliers, voire des dizaines de milliers de produits à gérer ? Bien sûr, vous avez besoin d'un outil de gestion de masse.

Vous avez choisi Merlin Backoffice? C'est un bon choix. Mais encore faut-il l'utiliser et le paramétrer. Voici les 10 meilleurs conseils à suivre, qui influencent directement les vitesses de traitement et d'affichage.


Modules concernés : Merlin Backoffice ™, PrestaPricing et PrestaCatégorie (tuto et captures d'écran réalisées avec PrestaPricing)

La vitesse d'envoi et de traitement des requêtes SQL


Pour une sécurité accrue, les requêtes HTTP (contenant elles mêmes les requêtes mySQL) peuvent être cryptées. Cela a un coût en terme de performance, le cryptage et surtout le décryptage coté serveur prend beaucoup de temps, jusqu'a doubler le temps total d'éxécution d'une requête.

Donc notre conseil N°1, à la recherche de la meilleure performance, est de décocher cette option dans la fenêtre de connexion de l'application :

Décocher le cryptage à l'envoie

Note : dans la version 1.4 de Merlin, il n'est pas autorisé de décocher cette option si la connexion n'est pas securisée (HTTPS://)


Le temps de lecture des données retournées par le serveur


Pour les mêmes raisons de sécurité, les données lues dans la base et renvoyées par le serveur peuvent être soient compressées, soient cryptées. On peut penser que la compression, puisqu'elle diminue le volume des données, accélère ce transfert. C'est vrai parfois, mais c'est sans tenir compte du fait que la compression et la décompression prennent du temps, et que bien souvent le bilan est négatif.

Notre conseil N°2, si vous êtes prêt à s'accrifier un peu de sécurité au profit d'une plus grande fluidité, est de choisir le mode "Ni encryptées ni compressées" :

Vitesse des données retournées


Accélérer le temps de chargement des catégories


Il est possible, pour ne pas dire fortement recommandé, de choisir le nouveau mode de chargement de catégories, dit chargement progressif.

Avec l'ancien mode, qui va disparaitre, sauf pour les versions de PrestaShop 1.2 et 1.3, toutes les catégories sont lues dans la base au lancement et affichées. Si cela s'avère pratique lorsque le nombre de catégories est raisonnable (moins de 300), cela devient vraiment lent au delà de plusieurs milliers.

Avec le mode chargement progressif, seul le premier niveau de catégories est lu, chargé en mémoire et affiché. Les sous catégories sont à leur tour affichées lorsque vous en avez besoin. Sur les très gros sites (30 000 catégories et plus), c'est jusqu'à 20 minutes de gagné au lancement.

Notre conseil N°3 est donc d'opter systématiquement pour le nouveau mode, lorsque le programme vous propose ce choix. Pour vérifier ou modifier votre choix précédent cochez cette option :

Choix de mode de chargement progressif

Cela ouvre cette fenêtre au moment de la connexion, optez donc pour le mode de chargement progressif, bien plus rapide :

Mode de chargement progressif bien plus rapide


Limiter le nombre de lignes affichées par page


Ces outils ont la capacité de travailler sur plusieurs centaines de milliers de produits ou déclinaisons en même temps. Si vous deviez faire la même chose en utilisant l'administration de PrestaShop, il vous faudrait des années, donc le gain de temps est phénoménal. Mais ce n'est pas une raison pour ne pas être efficace.

Les temps de traitement ont la fâcheuse manie d'augmenter de manière exponentielle avec le nombre de lignes. C'est a dire que le traitement de 5000 lignes n'est pas 5 fois mais 10 à 20 fois plus lent que le traitement de 1000 lignes.

Pour garder une certaine fluidité et éviter des temps d'attente trop longs, il devient donc essentiel de travailler page par page, avec pour chaque page un nombre de lignes raisonnable (que j'estime à 5000 maxi).

Cela est réalisable grâce aux paginateurs (et au super paginateur qui fixe la limite haute de réglage des paginateurs) :

Limiter le nombre de lignes par page

Voir cet autre tutoriel expliquant l'usage de ces paginateurs


Limiter le nombre de colonnes et bien les choisir


Ce conseil peut vous sembler évident, tant mieux. Mais nous voyons encore si souvent des utilisateurs qui travaillent avec toutes les colonnes affichées, soit plus de 90 pour la tables des produits.

Il n'y a rien de tel pour mettre à genoux votre serveur, avec des requêtes hyper complexes et des volumes de données gigantesques.

Pour gagner en fluidité, il faut vraiment prendre l'habitude de ne cocher que les colonnes dont vous avez vraiment besoin.

D'autre part, toutes les colonnes (ou rubriques de la base), ne se valent pas, certaines nécessitent plus de ressources et de puissance serveur que d'autres. Sitolog vous aide dans vos choix, les colonnes ayant une influence négative sur la vitesse sont indiquées. Plus vous en sélectionnez et plus il faudra attendre :

Rubriques jouant sur la vitesse de rafraichissement

De plus certaines colonnes indiquées  "hyper lent" le sont d'autant plus que plusieurs d'entre elles sont cochées. Évitez d'utiliser plus d'une de ce type de colonne à la fois. Le fait que 3 ou plus de ce type de rubriques soient demandées peut même faire planter les serveurs mutualisés les moins bien fournis en ressource mémoire et CPU.

Note : dans le nouveau "Configurateur de colonnes" de Merlin, les colonnes ayant un impact sur la vitesse de chargement des pages sont signalées par des pictogrammes (lent: -, très lent : -- ou hyper lent : ---) :

Nouveau sélecteur de colonnes


Utilisez le configurateur de colonnes


Justement parce qu'il est important de n'afficher que les colonnes essentielles à un travail donné, l’utilisation des pré-réglages ou "configuration de colonnes" permet de passer d'un choix de colonnes à un autre en un clic. Pourquoi s'en priver.

De plus savez vous que d'un simple clic droit dans la liste, vous pouvez nommer vos configurations ?

Configuration des colonnes

A venir, le nouveau configurateur permettant de réaliser un nombre illimité (au lieu de 6 actuellement) de configurations de colonnes, utilisant le glisser-déposer pour choisir les colonnes et pour les ré-ordonner. Possibilité également de choisir les titres affichés dans les tables et leur largeur :

Nouveau configurateur de colonnes permettant un nombre illimité de réglages


Limitez le nombre de tables "enclenchées"


Une table "enclenchée" est une table dont les données sont affichées et qui se rafraîchie automatiquement lorsque la table parente est rafraîchie ou que l'on change de ligne.

Par exemple la table des déclinaisons, si elle est enclenchée sera rafraichie automatiquement lorsque l'on sélectionne un produit dans la table des produits. Cela signifie que des requêtes de lecture des données des déclinaisons seront envoyées vers la base et traitées. Autant de temps perdu si vous n'avez pas spécialement besoin de voir les déclinaisons.

Si plusieurs tables sont enclenchées, par exemple les déclinaisons, la table des traductions et pire encore, les images, le durée nécessaire pour afficher les produits d'une déclinaison peut augmenter considérablement.

En résumé, pensez à dé-enclencher toutes les tables dont vous n'avez plus besoin que les données soient affichées. Vous verrez, vous gagnerez encore un temps fou.

Les tables sont enclenchées lorsque leur bouton "Engrenage" (sera peut être prochainement remplacé par un icône représentant un "œil") est enfoncé (fond orange):

Liaison entre tables et la base enclenchées

Note : dans Merlin, ces boutons "engrenages" ont été remplacés par des boutons "Affichage", qui prennent la couleur orange lorsqu'ils sont "enclenchés".

Décochez l'option "Compteurs de lignes"


Un truc tout bête mais à connaitre, le calcul du nombre de ligne et des totaux pour certaines colonnes, bien que pratique, peut aller jusqu'à doubler le temps de rafraichissement des pages et des tables. Donc à moins d'en avoir vraiment besoin, on vous conseille fortement de décocher cette option si la vitesse de rafraichissement est votre objectif premier :

Compteur de lignes


Utilisez les pré-filtres plutôt que les filtres de colonnes.


Houla dites vous, ça se complique...  courage on est presque au bout.

Un pré-filtre est un filtre limitant le nombre de lignes retournées par la requêtes SQL. Il agit directement au niveau de la requêtes elle même (est écrit en MySQL). Il est donc particulièrement efficace, rapide et peut réduire considérablement le volume de données envoyées par le serveur , augmentant ainsi la vitesse globale d'affichage.

Il existe des pré-filtres tout prêts, sur les fabricants ou fournisseurs par exemple et deux pré-filtres entièrement personnalisables. Un tuto leur sera consacré prochainement :

Pré-filtrage pour diminuer la durée des requétes

Un filtre de colonne, au contraire, agit en aval, une fois les données reçues du serveur et affichées dans la table, pour simplement masquer certaines lignes. Il n'apporte donc aucun gain de temps :

Filtre de colonne. Pas plus rapide.


Évitez de relire inutilement les catégories quand vous changez de langue


Lorsque l'on travaille sur les produits et souhaite passer d'une langue à l'autre, il est souvent inutile de faire rafraichir l'arbre des catégories.

Une petite option à cocher, peu connue, permet de faire ce choix. Cochez cette option et les catégories resteront affichées dans la langue en cours lorsque vous choisissez une autre langue pour afficher les produits:

Eviter le rafraichissement des catégories lorsque l'on change de langue

Deux autres réglages à désactiver également, les compteurs de produits dans l'arbre des catégories (nouveauté V 2.3.4) et l'affichage des jauges

Ces deux options d'affichage on en effet un impact très important sur les vitesses d'affichage des tables. A désactiver dans le panneau de contrôle, tiroir "Affichage".


Autres articles de la catégorie Astuces ergonomiques et réglages

Réglages
  • Identification
    • £ GBP
    • $ USD
Menu