Feature/cache

[manuelh78]

Bjr,
Afin d'accélérer le temps d'affichage sur la page MembersList, je propose d'implémenter un cache PSR-16 avec une gestion des dépendances entre résultats de requêtes.

Sur une base de plus de 5000 membres, l'affichage est un peu long.
D'après mes essais, on a un facteur 10 à 40 entre un accès à MySQL et un accès au cache.

Ça permet également de répondre au problème des requêtes SQL chronophages et redondantes : voir #464

En affichant 500 membres par page, la navigation reste "agréable".
Manuel

[trasher]

Merci pour la proposition.
Je n'ai rien spécialement contre, mais je ne dispose pas de base assez conséquente pour "tester" de manière réellement efficace.

Cette PR contient des commits qui ne sont pas en lien, il faudrait les supprimer. l faudrait également effectuer un rebase sur une branche develop à jour, il y a des conflits.

Enfin, toutes les méthodes doivent être documentées (et en anglais) ; ça ne passera pas les vérifications de CI.

[manuelh78]

Slt,
Avant de faire un code propre et documenté, j'attendais ton avis, pour ne pas passer du temps inutilement.

[trasher]

Je viens de tester vite fait, sur une base d'un peu plus de 600 adhérents, en affichant tous les adhérents : on passe de ~2000 ms à ~1700ms (avec un dossier cache stocké en ramfs).

Même constat sur chacune des page en affichant 200 adhérents à la fois, on constate très peu voire pas du tout de différence.

Mon instance de MariaDB est un peu modifiée - notamment pour suivre au mieux la mémoire installée sur ma machine ; mais on peu considérer qu'un hébergeur aura au moins aussi apporté ce genre de modification.

[manuelh78]

Slt,

Chez OVH en mutualisé, MariaDB est une option payante. Par défaut, c'est MySQL.

Leurs bases SQL sont stockées sur des serveurs indépendants de la partie web.

Les performances sont limitées par la mutualisation. Il n'est pas possible de dire où tu veux stocker le cache.

OVH propose le VPS 100% personnalisable, mais c'est réservé aux "spécialistes". Je suppose que 99% des installations de Galette sont sur des hébergements classiques ?

Dans mes tests, j'ai ajouté un suivi de l'accès au cache via Analog. As-tu désactivé le mode DEBUG ?

Il y a probablement quelques optimisations à faire, je pense à getDues() qui 'recalcule' à chaque demande une info qui pourrait être mise à jour uniquement en cas d'ajout ou de modifications des contributions.

Il y a également le temps que Twig passe à générer le tableau qui n'est pas insignifiant.

Avec le cache, on ne gagne pas un temps extraordinaire, mais c'est un moyen de répondre à ta remarque sur la PR #464.

Enfin, actuellement, il n'est pas possible d'afficher 5000 membres, puis cliquer sur 'tout cocher', puis faire un envoi de mails en masse. Il y a une exception Does not know what to batch :(

[trasher]

Chez OVH en mutualisé, MariaDB est une option payante. Par défaut, c'est MySQL.

Je ne pense pas que ça change grand chose de totues façons ; c'est surtout la configuration qui va jouer (et encore).

Leurs bases SQL sont stockées sur des serveurs indépendants de la partie web.

Hum... La latence réseau va certainement affecter les performances, mais je pense que leurs réseaux sont assez performants, pas sûr que ça ne change vraiment les choses sur quelques centaines de requêtes.

Les performances sont limitées par la mutualisation. Il n'est pas possible de dire où tu veux stocker le cache.

Vu que les performances restaient inchangées avec ou sans cache, j'ai entrepris de tester avec un cache bien plus rapide pour voir si les accès disques n'étaient pas en cause de mon côté - à titre de confirmation.

Dans mes tests, j'ai ajouté un suivi de l'accès au cache via Analog. As-tu désactivé le mode DEBUG ?

À la base , non, il y a peu d'infos de débug pour le coup. Je viens cependant d'essayer : on tombe à ~1000ms pour l'affichage de mes 600 et quelques adhérents, que ce soit sur ta branche, ou sur la branche develop.

Il y a probablement quelques optimisations à faire, je pense à getDues() qui 'recalcule' à chaque demande une info qui pourrait être mise à jour uniquement en cas d'ajout ou de modifications des contributions.

Mais qui devrait être stockée et mise à jour, ce qui cause d'autres problèmes. J'y avais déjà songé lors d'un chantier global d'amélioration des performances, mais le jeu n'en valait pas la chandelle : trop d'implications pour le peu de gains apporté.

Il y a également le temps que Twig passe à générer le tableau qui n'est pas insignifiant.

Le temps de génération global reste un indicateur. Sur 1000ms, que ce soit avec ta PR ou la branche develop, le temps de génération de twig est le même. Le but n'est pas de déterminer précisément le gain, mais de savoir s'il y en a un.

Avec le cache, on ne gagne pas un temps extraordinaire, mais c'est un moyen de répondre à ta remarque sur la PR #464.

Pas spécialement du coup, vu que je ne constate pas de différence de mon côté :/
Je n'ai pas d'hébergement mutualisé, je pourrai au mieux tester avec une base sur une autre machine et voir s'il y a vraiment un changement.

Je remarque également que l'impact de la génération du cache est quasi null aussi (ce qui est plutôt une bonne chose). Sur ta branche, que l'on affiche les 600 adhérents pour la première fois, ou que les informations soient lues depuis le cache : on reste à ~1000 ms (là par contre, je suis étonné, il aurait été logique que ce soit plus couteux).

Enfin, actuellement, il n'est pas possible d'afficher 5000 membres, puis cliquer sur 'tout cocher', puis faire un envoi de mails en masse. Il y a une exception Does not know what to batch :(

Idem, ça marche avec mes 600 et quelques adhérents :

Je pense qu'il s'agit d'une limite sur le nombre de variables envoyées en post ou la taille maxi autorisée. Quand on dépasse ce genre de limites, on obtient un POST vide, ce qui expliquerait le problème. Normalement, on a quelque chose dans les logs, mais sur un mutualisé, il est fort possible qu'on y ait pas accès.