Lenteur GRR (3.4.2d) - Githubissues

ovigy commented 2 years ago

Bonjour, je rencontre des problèmes de lenteur à l'affichage. J'ai suivi les messages (#129 et sur le forum) déjà rapportés pour essayer de résoudre le problème, sans succès.

Après la mise à jour de la 3.4.2b à la 3.4.2d (+ création de l'index dans la base grr_entry), le problème persiste. Le problème est criant en "week" sur un domaine avec tous les jours de la semaine, sur 24h avec chaque bloc au 1/4h. On ne récupère la main qu'une fois le planning/tableau totalement affiché. Avec une base "grr_entry" vide, l'affichage "week" d'une ressource prend une dizaine de secondes! Si la semaine à afficher est chargée, cela met 20-30s. Même l'affichage "week_all" met 20-30s sur la base de production (10000 entrées sur la base "grr_entry").

On est passé en octobre dernier de la version 3.3.1 à la 3.4.2b et c'est à ce moment là que le problème semble être survenu.

Cette lenteur est bloquante pour l'utilisation de l'outil au quotidien. Si quelqu'un a des suggestions, n'hésitez pas! Merci.

Bonne journée, Oana

Numéro de version GRR fichier : 3.4.2d 
Numéro de version GRR BDD : 3.4.2
Préfixe : grr
---
Système d'exploitation : FreeBSD www1.igf.cnrs.fr 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27 UTC 2021     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Version PHP : 7.4.26
Base de donnée : mysql 5.5.5-10.5.13-MariaDB-log
---
Time : 1642149585
Date du serveur (Jour-Mois-Annee) : 14-01-2022. Heure : 09:39
Timezone (date_default_timezone_set) : Europe/Paris

ovigy commented 2 years ago

Re, autres tests :

le site GRR répond bien quand la table "grr_entry" est vide (navigation sur "mon compte", "administration" très réactif) mis à part l'affichage "week" d'une ressource (7j, 24h, bloc d'1/4h) qui met 10s comme déjà décrit
avec la table "grr_entry" pleine avec 10000 entrées, GRR est très lent même la navigation "mon compte", "administration" etc.

On utilise les champs additionnels : 1 domaine à 8 ressources avec 8 champs additionnels / 1 autre domaine à 3 ressources et 6 champs additionnels.

Merci pour votre aide, Oana

ynaessens commented 2 years ago

Bonjour, pouvez-vous nous dire si ce correctif est efficace ? https://github.com/JeromeDevome/GRR/commit/205b3b5be4ddc5c5cce52641207e163441af751f Tant qu'à faire une mise à jour, n'hésitez pas à récupérer l'ensemble des modifications depuis la release 3.4.2d Cordialement, YN

ovigy commented 2 years ago

Bonjour, merci pour votre réponse et votre aide. En intégrant ce fichier corrigé, le problème persiste (avec la table _entry vide) pour l'affichage d'une ressource en mode "week" (c'est le cas le plus flagrant). Avec des données et en mode "month" sur une ressource, c'est également très long. Je peux bien évidemment faire des tests avec une version plus récente mais je pensais rester sur une version dite stable, la 3.4.2d étant la plus récente il me semble. Sur l'instance de test, je peux tester tout ce que vous voulez. Dites moi quel est le mieux? Cordialement, Oana

ynaessens commented 2 years ago

Effectivement, l'amélioration proposée ne s'applique qu'aux pages week_all, month et month_all2 ; elle n'est efficace que si des réservations sont déjà posées (au lieu de parcourir tous les créneaux, on passe de réservation en réservation jusqu'à trouver une plage vide). Donc, pour ce qui est de la page week, avec vos réglages (24 heures en tranches d'un quart d'heure), j'observe également une certaine lenteur (3 sec. au lieu de moins d'1 sec. pour les autres pages). 672 requêtes quand même... il faudrait voir pour procéder autrement... je mets cela en to-do list prioritaire ;-) Pour ce qui est des tests, si vous voulez contribuer à la finalisation de la 3.4.3, vous êtes bienvenue ! Cordialement, YN

ovigy commented 2 years ago

Merci pour votre retour et de tenir compte de notre blocage. La page week, sans données, prend 8s de mon côté pour que l'ensemble de la matrice heure/jour s'affiche totalement. Ma contribution ne peut malheureusement se résumer qu'à tester avec des données ancestrales (utilisation de GRR depuis la 1.9.7e!) et vous faire le retour le plus clair possible. J'avais par inadvertance installé la v4 il y a quelques mois et ça avait l'air top. Dans tous les cas, merci pour les développements réalisés. Cordialement, Oana

ynaessens commented 2 years ago

En comparant les codes des pages week entre les versions 1.9.7e et 3.4.2d, je ne vois pas ce qui peut provoquer cette chute de performance. Ayant introduit une nouvelle fonctionnalité de choix d'affichage du contenu des cellules dans la version 3.4.3, pouvez-vous me dire si le ralentissement se produit encore avec cette version ? Cordialement, YN

ovigy commented 2 years ago

On a fait plusieurs montés de version depuis la 1.9.7e. D'après les retours que j'ai, le problème de ralentissement est apparu depuis qu'on est passé de la 3.3.1 à la 3.4.2b. Je pourrai faire les tests sur la 3.4.3 la semaine prochaine et je vous tiens au courant. Merci et bon week-end, Oana

ovigy commented 2 years ago

Bonsoir, je m'excuse de ne pas avoir pu commencer les tests sur la dernière version comme je l'espérais. Je vous tiens au courant. Bon week-end, Oana

ovigy commented 2 years ago

Bonjour, j'ai donc testé la version 3.4.3 RC3 mais sans aucune amélioration des performances. Sur l'affichage "week" (sans données dans la table "grr_entry"), la matrice met toujours autant de temps à s'afficher, tout d'abord en bas de page avant de remonter à côté du menu gauche une fois qu'elle est complète.

Tests avec les nouvelles options d'affichage : toujours sur "week", même si je décoche toutes les options sur l'affichage du contenu des cellules (avec message "modification bien prise en compte"), les "horaires" et "short_desc" sont recochés automatiquement et s'affichent, en plus des champs additionnels.
Champs additionnels : je ne sais pas si cela joue mais on a quelques champs additionnels (<10) par domaine, j'ai essayé de modifier leur configuration afin qu'ils n'apparaissent plus sur les vues mais ils restent affichés ("Afficher le contenu dans les vues journées, semaine et mois").

Avez-vous des suggestions de test? Est-ce que vous fournir un dump de la base en 3.4.3 RC3 peut vous aider à debugger?

Merci pour votre aide. Cordialement, Oana

ynaessens commented 2 years ago

Bonjour, j'aimerais que vous précisiez si vous avez observé les lenteurs lorsque vous visualisez les plannings sans être connecté. Pour ce qui est des informations affichées, avez-vous pensé à enregistrer les changements ? Si oui, pouvez-vous vérifier dans la table grr_setting la valeur de cell_week ? De même pour les champs additionnels, leur attribut 'affichage' ? Merci pour vos retours, cordialement, YN

ovigy commented 2 years ago

Bonjour, tous les domaines de notre GRR ne sont accessibles qu'après connexion. Vous trouverez ci-dessous le détail des réponses à vos demandes de test. Il semble effectivement qu'il y ait une différence de comportement entre le mode connecté et déconnecté : vitesse + affichage du contenu des plannings.

En levant ces restrictions pour une ressource d'un domaine ("il n'est pas nécessaire de se connecter pour voir les réservations" + accès non restreint sur le domaine + "n'importe qui peut voir la ressource"), cela semble effectivement plus rapide.
Pour les informations affichées, j'ai retesté et en décochant toutes les options de week_all par ex, j'enregistre, le pop-up "les modifications ont été enregistrées" s'affiche mais les 2 options "horaires" et "short_desc" sont re-cochées automatiquement.

Voilà la relation entre l'interface et le contenu de la table grr_setting, ce qui a l'air cohérent.

| cell_day                         | VFVFFFF 
| cell_month                       | VFVFFFF 
| cell_month_all                   | VFVFFFF
| cell_month_all2                  | VFVFFFF 
| cell_week                        | VFVFFFF 
| cell_week_all                    | VFVFFFF
| cell_year                        | VFFFFFF
| cell_year_all                    | VFFFFFF

setting_planning

Test : J'ai modifié directement dans la table la valeur de cell_week_all en mettant tout à faux, l'interface d'admin indique bien ces changements (tout est décoché) et la vue du planning n'affiche plus que les champs personnalisés.

Pour les champs personnalisés : dans l'interface d'admin, en décochant les champs pour l'affichage, la table "grr_overload" est bien modifiée mais les champs restent affichés dans le planning en mode connecté mais pas en étant déconnecté!

| id | id_area | fieldname             | fieldtype | fieldlist | obligatoire | affichage | confidentiel | overload_mail | mail_spec |
|  3 |       1 | NB blanc              | text      |           | y           | n         | n            | n             |           |
|  4 |       1 | NB standard           | text      |           | y           | n         | n            | n             |           |
|  5 |       1 | Redmine - n° fiche    | text      |           | n           | n         | n            | n             |           |
|  6 |       1 | Qualité contrôle      | list      | Oui|Non   | y           | n         | n            | n             |           |
|  7 |       1 | Nb réinjection        | text      |           | y           | n         | n            | n             |           |
|  8 |       1 | Nb échantillon        | text      |           | y           | n         | n            | n             |           |
|  9 |       1 | Extrait - référence   | text      |           | y           | n         | n            | n             |           |
| 10 |       1 | QC NB                 | text      |           | n           | n         | n            | n             |           |

mode connecté planning_weekAll

mode déconnecté planning_weekAll_deconnecte

Désolée, les tests sont hyper longs à cause du temps de réponse de GRR! Merci pour votre aide Oana

ynaessens commented 2 years ago

Merci pour votre retour : vos tests sont instructifs ! Voici un premier correctif pour la prise en compte des options désélectionnées dans les affichages de cellules. https://github.com/JeromeDevome/GRR/commit/28ce3bcfc55c1ef280da710c9fa7559a2e02d877 J'étudie la suite...

ynaessens commented 2 years ago

Pour ce qui est des champs additionnels, ils s'affichent systématiquement lorsque l'utilisateur est administrateur général ou de site. Si vous voulez le supprimer, je peux vous indiquer la modification à faire.

ovigy commented 2 years ago

Les champs additionnels sont vraiment informatifs dans la vue planning donc c'est ok pour les conserver, merci.

ynaessens commented 2 years ago

Bonjour, je suis remonté jusqu'en V3 RC1 pour confirmer l'hypothèse de modification de code qui aurait pu ralentir le chargement des pages, mais je n'ai rien trouvé de significatif. Je pense que c'est le nombre de cellules à calculer dans votre configuration de 24 heures divisées en quarts d'heure qui provoque ce délai. Comme j'ai remarqué que parfois c'est le chargement de la page (donc côté navigateur) qui est long, je vous propose d'essayer de désactiver la mise en forme des cellules en supprimant les lignes 781 à 788 du fichier week.php (version 3.4.3 en cours). Cordialement, YN

ovigy commented 2 years ago

Bonjour, j'ai fait la modification sur le fichier "week.php" mais je ne note aucune amélioration de vitesse d'affichage malheureusement. En étant en mode déconnecté (d'après vos conseils), l'affichage est bien plus rapide et "normal" pour utilisation (avec et sans modification de ce fichier). On utilisait la 3.3.1 depuis 2018 sans problème (sans changement de configuration, planning 24h et 1/4h, etc.). On est passé en v3.4.2b à cause d'un bug sur la 3.3.1 d'impossibilité de modifier une réservation suite à une maj PHP? Le problème de lenteur est devenu flagrant à ce moment là. Cordialement, Oana

ynaessens commented 2 years ago

La version 3.3.1 n'est pas compatible avec php7. Je viens de reprendre encore une fois le code de la 3.3.1 en la comparant à la 3.4.2, sans trouver d'où vient le ralentissement. A priori, celui de la 3.4.3 devrait être un peu plus rapide. Je garde votre problème en haut de la liste, mais je ne vous cacherai pas ma perplexité.

ovigy commented 2 years ago

Merci pour vos retours. Je vais voir ce qu'on peut faire/tester d'autres. Cordialement, Oana

ovigy commented 2 years ago

Bonjour, la différence de temps d'affichage en mode connecté ou déconnecté est flagrante : +15/20s pour l'affichage d'une matrice "week" sans réservations (tous les 1/4h sur 24h). J'ai essayé avec un compte utilisateur non administrateur. Je suis en train d'essayer de réinstaller une v331 avec nos données pour m'assurer que ces problèmes n'étaient pas rencontrés, je vous tiendrai au courant. Cordialement, Oana

ynaessens commented 2 years ago

Bonjour, j'ai modifié le code de la page week.php. Il me semble que l'affichage est plus rapide, même avec une journée entière découpée en quarts d'heure. Si vous pouviez me confirmer que le commit https://github.com/JeromeDevome/GRR/commit/a8438b7a9b4fe3565dacc3d948261337df8fc49f améliore le temps de calcul et d'affichage (a priori le remplacement de ce seul fichier doit être opérationnel sur une 3.4.3), je pourrais tourner la page :-) Cordialement, YN

ovigy commented 2 years ago

Bonjour, merci d'avoir gardé ce problème à l'esprit. J'ai installé le fichier "week.php" mais sans noter d'amélioration. C'est vraiment en mode connecté que les temps d'affichage sont interminables (15-20s), quelle que soit la vue (week-month-all etc.). En étant déconnecté, c'est tout à fait correct. Malheureusement, on souhaite continuer d'utiliser GRR avec des comptes utilisateurs avec des accès limités sur les réservations. J'ai essayé de réinstaller la 3.3.1 pour comparer les temps (avec ce qui nous semblait acceptable avant) mais je suis coincée sur la page de connexion "Le site est momentanément inaccessible. Veuillez nous excuser de ce dérangement !" sans savoir comment repasser en mode ok (avec un compte administrateur bien sûr). Donc j'ai abandonné cette piste et on utilise la 3.4.2e très patiemment. Si vous voulez y jetez un œil en direct, dites le moi. Merci pour vos efforts. Cordialement, Oana

ovigy commented 2 years ago

1 question : la fin du support PHP 7.4 est annoncée pour le 28 novembre 2022 ; est-ce que GRR est/sera compatible PHP 8.0? Dans les pré-requis, il est indiqué PHP <= 7.3 Cordialement, Oana

ynaessens commented 2 years ago

Bonjour J’utilise couramment php 7.4 et les premiers tests avec php 8.0 sont encourageants. La compatibilité avec les vieux php 5.6 risque de devenir difficile à maintenir… Cordialement YN

ynaessens commented 2 years ago

Bonjour, pour vos problèmes de lenteur d'affichage, je veux bien un accès à votre site. Il faudrait trouver un canal d'échange discret... peut-être sur le salon GRR de Discord ? Pour ce qui est des pages week_all, month et month_all, je n'ai pas révisé le code car selon mon analyse, c'est côté navigateur que les lenteurs se produisent dans week. D'où l'idée de supprimer le Javascript de centrage des cellules et le remplacer par un attribut css. Cordialement, YN

ovigy commented 2 years ago

Bonjour, je n'ai pas vu où trouver le salon GRR de Discord. Si vous voulez, nous pouvons échanger par mail (oana.vigy at fpp.cnrs.fr). Pour avoir accès à notre site, il nous faudrait votre adresse IP pour vous autoriser l'accès. Merci. Cordialement, Oana

JeromeDevome / GRR

Lenteur GRR (3.4.2d) #172