Lenteur sur 19.0.3

[Valdu]

Bonjour,

Je viens vers vous tous pour me conseiller dans mon problème.

En effet j’ai opté pour Dolibarr en Aout 2023.

Cela plus d’un an que cela fonctionne bien. Dernièrement, j’ai pas mal de ralentissement au niveau de l’affichage des pages. De temps en temps, Dolibarr reste planté 10 à 20 secondes lors la mise de à jour de tarif ou ajout de produit dans les propositions ou commande.

Le record pour le moment est du niveau de la marge par client avec au minimum 40 secondes.

J’utilise O2Switch en PHP 8.2. En passant par softaculous.

J’ai même essayé sans les modules et c’est la même chose. ou encore de désactivité les PDF automatique. J’ai tester les requêtes directement dans PHPmyAdmin, le temps est ridicule.

Je ne sais pas d’où vient le problème.

[defrance]

hello j’ai ce genre de blague qui c’est réglé en changeant le nom du serveur de la base de données par son adresse ip

[Valdu]

J’ai essayé en lisant les autres réponses à des questions plus ou moins similaire mais cela ne change rien. (127.0.0.1)

[libremaster]

Il doit y avoir un problème d’index à regénérer ou à ajouter sur un des champs d’une table impliquée dans le ralentissement. Ce n’est pas trivial mais il faut regarder les champs un à un et tester.

[defrance]

Si c’était un probleme d’index, on aurait des performances merdiques à la fois dans dolibarr et dans phpmyadmin, ce qui ne semble pas etre le cas.
je pense plus à un pilote mysqli qui n’est pas super optimisé c’est le paramètre dolibarr_main_db_type dans le fichier conf.php

[Valdu]

J’ai essayé de revoir deux trois index mais rien de concluant. Je regarderais quand même.

[Le_Reparateur]

Bonjour
Une base de données (articles) qui aurait désormais une grosse quantité de ligne ?
Un module ajouté qui provoquerait des accès sur la base ?
Utilisez vous un cache mémoire pour améliorer les choses ?
Francis

[Valdu]

Plus de 60 000 articles, 115 000 prix d’achat différents, dans un clone j’ai désactivé les modules, cela n’a rien fait. J’ai tester Memcached, LSCache, XTremcache, etc… mais rien n’y fait.

[defrance]

en regardant votre premiere image de log, je constate qu’il y a une requete qui prend plus de 390s
n’est-ce pas celle là qui pose problème et pas la dernière?

[libremaster]

Si le champ tosell de la table llx_product n’a pas d’index, il faut en ajouter un.

[defrance]

peut etre aussi ajouter un index sur p.stock si il n’existe pas

[Valdu]

Je pense que c’est un problème de conversion, c’est 300ms.

Voici les réglage du fichier conf :

$dolibarr_main_db_host=‹ localhost ›;

$dolibarr_main_db_type=‹ mysqli ›;

$dolibarr_main_db_character_set=‹ utf8 ›;

$dolibarr_main_db_collation=‹ utf8_general_ci ›;

$dolibarr_main_authentication=‹ dolibarr ›;

$dolibarr_main_prod=‹ 0 ›;

$dolibarr_main_force_https=‹ 1 ›;

$dolibarr_main_restrict_os_commands=‹ mysqldump, mysql, pg_dump, pgrestore ›;

$dolibarr_nocsrfcheck=‹ 0 ›;

$dolibarr_mailing_limit_sendbyweb=‹ 0 ›;

$dolibarr_mailing_limit_sendbycli=‹ 0 ›;

[defrance]

c’est en tout cas la plus grosse valeur dans les requetes

[Valdu]

Déjà fait.

[Valdu]

Fait aussi.

[libremaster]

Si le serveur manque de mémoire ou qq chose comme ça, il va écrire plus sur le disque des tables temporaires j’imagine. C’est peut-être un problème d’optimisation de la puissance des serveurs.

[libremaster]

phpMyadmin permet d’afficher les variables d’état du serveur avec des statistiques et des lignes en rouge pour suggérer le changement de réglage du serveurs sql.

[Valdu]

On a aussi regardé sur ca et rien de bizarre ou long dans les requêtes.

[Valdu]

Le principale problème, c’est surtout les moments ou on a une longue pause sur le chargement des pages. C’est très fluide, et d’un coup, tout ralenti.

[ygspace]

Bonjour,

Avez-vous résolu votre problème de lenteur ?
Pouvez-vous décrire votre système de serveur ? linux windows, etc… hébergement externe …