Je viens solliciter votre aide ou votre expérience. J’ai installé Dolibarr sur nos serveurs pour un ami/client qui possède plusieurs magasins.
J’ai intégré un module Multisociété afin de gérer l’ensemble des franchises, et jusqu’ici tout fonctionne correctement.
Cependant, je fais face à des problèmes de lenteur au niveau de la base de données, malgré des ressources serveur apparemment adéquates (CPU XEON E3-1240 V6, 16 Go de RAM, 100 Go SSD).
Le problème réside dans le grand nombre de tickets générés quotidiennement par magasin, ce qui rend les listes extrêmement lentes à charger.
L’année dernière, j’ai ajouté le module Memcached, ce qui a amélioré la fluidité, mais aucune amélioration n’a été constatée au niveau de la base de données.
Y a-t-il des ajustements que nous pouvons effectuer pour optimiser les performances et obtenir une meilleure fluidité ? Peut-être existe-t-il des options cachées que nous pourrions configurer ?
Dans le navigateur regarder le trafique réseau (F12) et voir les appels qui prennent le plus de temps (exemple : est-ce que l’affichage des listes avec 10000 lignes par défaut est une bonne idée ?). Analyser ces appels, qu’est ce qui prend du temps, le serveur est à la traîne, ou la taille de la page renvoyé par le serveur est trop importante (une page de 2Mo sera toujours lente à charger, quoi qu’on fasse, bon avec la fibre ça se sens moins mais quand même)
Étudier le code des pages appelées qui sont lentes, il y a peux être des optimisations à proposer à la communauté
Étudier les log de Dolibarr (module trace et log) de ces appels pour voir les requêtes SQL qui prennent du temps
LoadBalancing reseaux avec marriadb répliqué sur plusieurs serveurs
Si vous n’avez pas actuellement la connaissance dans l’administration système Linux ou de compétences dans l’administration de base de données, 2 solutions :
apprendre
se faire aider par un professionnel (là dessus les partenaires Dolibarr peuvent répondre, mais une petite recherche sur un site freelance vous permettra de trouver des personnes avec ces compétences, c’est presque pas du spécifique Dolibarr)
@FHenry Merci pour ton message ! Je vais prendre le temps d’analyser plus en profondeur et je reviendrai avec mes conclusions.
La lenteur semble être spécifique à la liste des factures. J’ai l’impression qu’il tente de charger les 260 000 factures/tickets alors que le listing affiche seulement 20 éléments à la fois. Il faudrait une fonction d’archivage
@MFZ
L’archivage … ça n’existe pas dans Dolibarr par contre on peut demander des filtres par défauts sur les listes avec Accueil->Configuration->Valeurs/filtres/tris par défaut->« onglet » filtre par défaut : Faut comprendre le HTML
Sinon des marques pages avec la liste des factures (si c’est bien compta/facture/list.php qui est lent) avec des filtres sur la ref qui exlue les tickets (!TC_) par exemple
@FHenry non aucun module ni modification spécial. Oui les deux pages compta/facture/list.php et historique takepos. On est que pour takepos le dolibarr donc que des TC dans le système. Aucun stock ne produit aucun client, juste un client générique.
L’historique de TakePos c’est la page compta/facture/list.php (la même que sur dolibarr backoffice) mais dans une popup. Dans votre cas, c’est logique que les deux pages aient le même problème.
Maintenant que vous savez quelle page (compta/facture/list.php), vous pouvez regarder ce qui se passe dans les log Dolibarr pour analyser les requêtes et ce qu’il est possible d’optimiser.
MAIN_DISABLE_FULL_SCANLIST ► Disables the complete scan of tables to allow the pagination to show total number of pages. May be useful to activate on systems with a very high quantity of data (tables with more than 2 000 000 records).
MAIN_DISABLE_FULL_SCANLIST = 1,
@FHenry Incroyable ! Cela a nettement amélioré l’ouverture de l’historique !!! Je n’avais pas vu cette option !!! Je ne pense pas que ce soit encore parfait au niveau de la vitesse, mais c’est bien meilleur ! Un grand merci !
la joie de la théorie et de la pratique…
j’ai des environnement ou le fait de passer de localhost à 127.0.01 m’a fait gagné 2s à chaque ouverture de page… les joies des dns un peu foireux chez windows…
J’ai parlé trop vite… Ça n’a pas réellement changé, c’était mon memcached…
Ce matin, je fais quelques tests et je vois que les lenteurs sont toujours là mmm. Je vais devoir chercher plus loin. Par tout hasard est-ce que la V15 est bon pour un grand volume de facture/ticket ?
Ne voyant rien de particulier dans les logs. Nous allions justement faire un clone de l’instance pour le passer en V18 pour faire l’essai ! Merci de l’information.
Je reviendrais quoi qu’il arrive pour donner mon retour sur cette résolution !
