Affichage page configuration modules TRES lente (>40s)

Bonjour,

Sur quelques-unes des instances que je maintiens, l’affichage de la de page configuration module est TRES lente (>40s)

Après quelques investigations, j’ai réussi dans certains cas seulement malheureusement à annuler cette lenteur (*)
en mettant la constante (Configuration → divers)
PATASMONKEY_SKIP_CHECKVERSION = 1

Si vous avez d’autres astuces …
Bonne journée

(*) la fonction getVersion des modules Patas-Monkey, appelle un changeLog dont l’url
http://dlbdemo.patas-monkey.com/htdocs/custom/customline/changelog.xml
est valide, mais qui n’arrive pas à se charger, peut-être du fait que je suis en hébergement mutualisé, ou que le FW bloque ces requêtes

Posons la question à @defrance

1 « J'aime »

Bonjour,
Effectivement, le module vérifie la présence d’une nouvelle version du module sur mes serveurs et effectue pour cela une requête.
Cela ne peu etre FW (ou alors c’est celui de ton hébergeur…)
Pour les autres cas, est-ce que tu as analysé les temps d’accès avec ton navigateur ou la console de débugage native de dolibarr?

Est-ce que la résolution DNS sur l’hébergement fonctionne ?

2 « J'aime »

Bonjour :slightly_smiling_face:
Et si l’url est en https ca va mieux?

Bonjour,
Merci de ta réponse.
J’ai tracé au moyen d’appels de dol_syslog rajoutés dans /admin/modules.php puis dans ton module.
Cela ne vient pas de mon navigateur puisque cela s’effectue côté serveur.
Je viens de tester côté serveur (debian 12) : effectivement, soucis de résolution de nom qui expliquent le soucis.(*)
N’empêche qu’un accès systématique à un changelog distant par potentiellement chaque module à chaque appel de la page modules est un peu « lourd et risqué », et je crois d’ailleurs bien me souvenir qu’Eldy a dit au devcamp de Bordeaux que cela serait bientôt interdit …

(*)J’ai moi-même expérimenté des soucis de nslookup (communications error to 127.0.0.1#53: timed out) sur mon poste en Ubuntu 22.04 LTS, qu’une mise à jour récente a corrigé

J’ai remonté ce type de problème sur des installations locales ou le temps de réponses à ma base de données n’était pas les meme entre 127.0.0.1 et localhost…

Pour en revenir a l’accès de mes modules au fichier ce changelog,
Tout d’abord ce n’est pas une page html mais un fichier xml hébergé sur mon site, je n’ai pas regardé coté performance si il était préférable d’utiliser du https ou un ip (mais bon là ce serait une tres mauvaise idée je pense).
C’est pour éviter des soucis de perf (je te laisse imaginer sinon le temps d’accès sur mon poste de dev avec mes 40 modules…), qu’il existe une variable qui bloque cette fonctionnalité mais il n’est plus possible alors d’alerter les utilisateurs de mes modules (et envoyer un mail à chaque mise à jour n’est pas une solution).

Ensuite je vois mal comment interdire ce genre de chose, je n’ai pas analyser les modules d’autres société mais il me semble qu’il y a avait eu certains modules assez « indélicat » dans ce domaine (et dans le cas de mon module, il s’agit de récupérer des données depuis un serveur distant, pas d’en envoyer…)

Mais si dans les prochaine version de dolibarr, li y a une solution plus fiable et sécure pour réaliser ce genre de chose, ben je suis preneuse (mais j’avoue que j’en doute…)

Bonjour,

Je pense qu’il faudrait une page indépendante de vérification des versions des modules, distincte de la page de configuration générale des modules.
Cela permettrait de ne pas faire la requête à chaque fois qu’on va peaufiner la configuration des modules.

1 « J'aime »

Re

Oui ou dans la page existante des modules une case à cocher pas cochée par défaut, qu’on coche unqiuement quand on veut checker les versions.
Vraiment pas compliqué à coder ça, si j’ai 30min pour faire un PR …

j’ai 40 modules à modifier si cela te chante… pas juste un PR…

Bah sauf si dans /admin/modules, on modifie les appels getVersion
if ($casecoche) {
$version = $objMod->getVersion(xx);
} else {
$version = $objMod->version;
}
Un peu sauvage certes, mais efficace à priori

yaka lol
on se demande bien pourquoi on a mis en place une fonction getVersion…

le code en question sur mes modules :

// skip check version of our modules
if ($action == 'patasMonkeySkipCheckVersion') {
dolibarr_set_const($db, "PATASMONKEY_SKIP_CHECKVERSION", GETPOST('value'), 'chaine', 0, '', $conf->entity);
}
$patasMonkeySkipCheckVersion=!empty($conf->global->PATASMONKEY_SKIP_CHECKVERSION);
print '<table class="noborder" width="100%">'."\n";
print '<tr class="liste_titre">';
print '<td width="20%">'.$langs->trans("PatasMonkeySkipCheckVersion").'</td>';
print '<td>'.$langs->trans("InfoPatasMonkeySkipCheckVersion").'</td>';
print '<td width=100px align=left>';
if ( $patasMonkeySkipCheckVersion == 1) {
print '<a href="'.$_SERVER["PHP_SELF"].'?action=patasMonkeySkipCheckVersion&token='.newToken().'&value=0">';
print img_picto($langs->trans("Enabled"), 'switch_on').'</a>';
} else {
print '<a href="'.$_SERVER["PHP_SELF"].'?action=patasMonkeySkipCheckVersion&token='.newToken().'&value=1">';
print img_picto($langs->trans("Disabled"), 'switch_off').'</a>';
}
print '</td></tr>';
print "</table>";

De toutes façons, cela ne résoud pas le ralentissement pour d’autres modules manifestement, donc pas de solution même sauvage
Là je teste sur un hébergement mutualisé type OVH et c’est très pénible (et ça ne vient pas des modules Patas puisque j’ai mis la cste PATASMONKEY_SKIP_CHECKVERSION =1)

Hello all,
c’est un peu dans ce sens que j’avais proposé ça il y a quelques temps : CAP-REL / dolibarr / moduleVersion · GitLab qui me semblerait être une bonne piste …

Mais la meilleure solution serait que dolibarr fasse une seule requête sur dolistore pour récupérer tout simplement une liste de tous les modules dispo avec leur numéro de version

soit sous la forme d’un bon vieux « format à la CSV »

module:1.0.1
toto:1.0.54
tata:15.0.25

soit du json ou du yml peu importe mais ça serait un service rendu par le dolistore que ça me semblerait assez normal …

… et actuellement le changelog des modules créer avec le générateur de module natif sont au format md… bon courage pour le parser et l’analyser…

Pour ma part je suis partie sur du xml dans mes modules, mais le format n’est vraiment pas une contrainte, mais je ne sais pas ou il serait bon de conserver les changelog des modules, et le dolistore n’est vraiment pas à mon sens une solution pérenne car cela oblige de diffuser sur cette plateforme tout les modules si on veux suivre les versions (sans parler que l’on risque d’avoir un jolie DDOS si tous le monde se crée des outils de scrapping sur ce dernier)

Une remarque cependant, chaque module doit avoir un numéro de version unique, à préciser dans le fichier mod…class.php , cela pourrait servir de clé d’accès au changelog conserver quelque part

je peux proposer mon bout de code de gestion du changelog en xml si jamais, ce n’est pas la panacée mais je doute que l’on puisse pour le moment trouver mieux…

Sauf erreur de ma part, la page dolibarr qui liste les modules n’a besoin que de savoir quelle est la dernière version disponible pour l’afficher à l’administrateur non ?

Le changelog n’est pas nécessaire à cette étape il me semble … donc pourquoi alourdir la charge utile ?

Au niveau du dolistore ça serait à mon avis TRES facile d’avoir un fichier d’index qui liste les modules + version vu que l’information est dans la BDD de dolistore et de mettre ce fichier accessible sur une url directe.

N’ayant pas connaissance de tous les id de tous les modules je me suis limité à ma liste de mes modules sur le code proposé sur le dépôt git pointé dans mon message précédent.

Si on cherche à optimiser le dolistore pourrait faire un fichier d’index à partir de sa bdd, stocker ce fichier sous la forme d’un fichier plat dans son arborescence publique et c’est tout. C’est ce que fait le code que j’ai proposé … avec un rafraîchissement automatique du cache.

De là à imaginer un DDOS je ne vois pas du tout la différence avec un DDOS sur https://dolistore.com/ tout court …

Sur la page des modules, les changelog sont affichés dans le mini popup quand on clique sur le petit icône (i) ou (?) en haut à droite des modules complémentaires.

Oui mais ça ne télécharge le fichier que lorsqu’on clique sur l’onglet « ChangeLog » non ? /admin/modulehelp.php?id=xxxx&mode=changelog

Tiens je vais aller lire le code de cette partie de dolibarr moi :slight_smile:

Bon courage pour t’y retrouver dans le code.

Depuis que j’ai commencé à me plonger dans le code, je suis horrifié toutes les 10 lignes et j’envoie pour l’instant des micro-patchs. Étant habitué du code propre avec Django, je reviens 20 ans en arrière avec Dolibarr.

Je trouve aussi des aberrations logiques dans certains modules complémentaires.