Lenteur fréquente (10/30sec) sur reservation de ressource

Bonjour,

je suis nouveau sur GRR et récupère une installation sur mon campus. Celle-ci comporte une quinzaine de sites ayant tous un peu plus d'une dizaine de ressources en gestion, pour environ 500 Utilisateurs. Le site est fréquenté régulièrement mais non de facon intensive.

Lorsque l'on clique (administrateur ou utilisateur standard) sur le "plus" pour ajouter une nouvelle reservation (n'importe laquelle), celle-ci s'ouvre soit souvent après plusieurs dizaines de secondes, cependant la meme reservation peut aussi s'ouvrir instantanément.

L'architecture est la suivante :
serveurs frontaux apache dédié -->  serveurs applicatif php fpm dédié --> cluster base de données mysql galera dédié.

Frontaux apache, avec ou sans modsecurity le soucis et le meme.
PHP: max 15 process enfant, 128M de ram, j'ai tenter d'augmenter les ressources sans succes.

Le seul log que j'ai est celui-ci qui apparait sur les longs ralentissement:
[20-Sep-2023 08:04:43]  [pool grrMultiSite] pid 1373824
script_filename = /path/grrMultiSite/edit_entry.php
[0x00007f7c75a13c70] mysqli_query() /path/grrMultiSite/include/mysql.inc.php:76
[0x00007f7c75a13be0] grr_sql_query() /path/grrMultiSite/include/functions.inc.php:3567
[0x00007f7c75a13aa0] authGetUserLevel() /path/grrMultiSite/include/functions.inc.php:4178
[0x00007f7c75a139a0] verif_acces_ressource() /path/grrMultiSite/edit_entry.php:705

 WARNING: [pool grrMultiSite] child 1421404, script '/path/grrMultiSite/edit_entry.php' (request: "GET /reserver/edit_entry.php?room=250&hour=08&minute=00&year=2023&month=9&day=21&page=day&room_back=all") executing too slow (39.151640 sec), logging


J'ai remarqué un comportement anormal dans les logs mysql sur la requete : Query    SELECT statut FROM grr_utilisateurs WHERE login='ASSISTAN'  AND etat='actif'.
Lorsque la reservation fonctionne correctement, elle apparait 50/70 fois. En revanche sur un ralentissement elle apparait plusieurs milliers de fois.

Ce comportement est observé en utilisant le meme utilisateur sur la meme ressource.

La je ne sais plus ou regarder, je viens de réaliser l'upgrade en version 4.1.1 cela ne change rien.

Un petit coup de main ne serait pas de refus .

Merci

Bonjour,
j'ai apporté des modifications au code sur la version 3.5.1.
Les informations que vous donnez sont intéressantes, aussi, si ce n'est pas trop de travail pour vous, ce serait bien de voir si les modifications pallient le problème de lenteur que vous constatez et si ces appels multiples persistent.
Merci pour votre compréhension.
Cordialement,
YN

Bonjour Yan,
merci pour votre réponse. Aucun soucis pour apporter des modifications sur mon installation, par contre il va falloir me guider un peu . Qu'est ce que je doit récupérer de la 3.5.1 (fichier/ligne de code/configuration/...) et ou dois je le déployer dans ma version 4.1.1?

Lionel

Il n'est pas possible de rétrograder une 4.1.1 en 3.5.1.
Si vous avez des données antérieures à la montée de version en 4.1.1, ce sont celles-là qu'il faudrait insérer dans la 3.5.1.
La dernière version de la branche 3 est là : github.com/JeromeDevome/GRR/releases/tag/v3.5.1a

Malheureusement je ne pourrait pas faire cela. Mon prédecesseur etait déjà monté courant avril en version 4.0.3.
Et a priori d'apres les logs php que j'ai pu retrouvé le problème a commencer a apparaitre a ce moment la.

Puisque c'est ainsi, avez-vous activé la possibilité de réserver la ressource au nom d'un autre utilisateur ?
Si oui, y a-t-il une amélioration en désactivant cette possibilité ?

Ok je vais essayer ca.
En cherchant dans le forum j'ai bien trouvé que ca se matérialiser via la table grr_room champ qui_peut_reserver_pour valeur 3... par contre suis pas un pro sur l'interface du coup je sais pas ou changer cette valeur étant donné que j'ai des utilisateurs dans ce cas.

Bonjour,
réserver pour est une propriété de la ressource, cela se règle dans la page de configuration de la ressource.
Cordialement,
YN

A priori sur la ressources concernées je n'ai pas de personne configuré pour utiliser ce droit. Du coup retour case départ. Ce qui est tres ennuyeux car les utilisateurs ralent (a juste titre)

Bonjour,
je viens d'essayer de tracé la partie qui ralenti le process, celui ci semble se situer dans le code ci-après qui execute vraiment beaucoup de requete. La boucle for de premier niveau mets plus d'une minute a s'éxécuter, et envoi de tres nombreuse requete mysql.

Code problématique (edit_entry.php)

699 for ($i = 0; ($row = grr_sql_row($res, $i)); $i++)
700 {
701 if (authUserAccesArea(getUserName(), $row[0]) == 1)
702 {
703 print " case \"".$row[0]."\":\n";
704 $sql2 = "SELECT id, room_name FROM ".TABLE_PREFIX."_room WHERE area_id='".$row[0]."'";
705 $tab_rooms_noaccess = verif_acces_ressource(getUserName(), 'all');
706 foreach($tab_rooms_noaccess as $key)
707 {
708 $sql2 .= " AND id != $key ";
709 }
710 $sql2 .= " ORDER BY room_name";
711 $res2 = grr_sql_query($sql2);
712 if ($res2)
713 {
714 $len = grr_sql_count($res2);
715 print "roomsObj.size=".min($longueur_liste_ressources_max,$len).";\n";
716 for ($j = 0; ($row2 = grr_sql_row($res2, $j)); $j++)
717 {
718 print "roomsObj.options[$j] = new Option(\"".str_replace('"','\\"',$row2[1])."\",".$row2[0] .")\n";
719 /* if (($j == 0)&&;($row[0] == 4))
720 $room = $row2[0]; */
721 }
722 print "roomsObj.options[0].selected = true\n";
723 }
724 print "break\n";
725 }
726 }