Envole » Envole-Mutualisé » eole-dispatcher

J'ajoute une précision importante et qui change tout :
notre paramètre "Durée du cache ARENA" était très bas (6 heures)
Cela explique ce comportement : en effet, et en particulier la nuit, tous les caches étaient potentiellement obsolètes, donc il était obligé de les traiter tous
J'ai passé ce paramètre à 30 heures, et le problème ne se produit plus

Toutefois, une discussion avec Pierre a conduit à la conclusion suivante : l'idéal serait d'avoir un cache d'une longue durée de vie pour éviter les chargements trop lents à la connexion des utilisateurs, mais en même temps un cron qui mettrait à jour la nuit les caches des utilisateurs. Ainsi on aurait les deux avantages : cache toujours à jour ET chargement rapide du bureau

Mais pour cela il faudrait que le cron ne tienne plus compte du paramètre de durée de vie du cache, mais traite tous les caches, en commençant par les plus anciens

Qu'en penses-tu ? Je vais étudier cela de mon côté en faisant bien sur attention aux problèmes potentiels de performance

Nouvel update qui tempère un peu le post précédent : en fait le fichier .lock s'était bloqué à 5h00 du matin , ce qui forcément a fait chuter drastiquement les appels au webservice (j'ai été averti par la salle machine ce matin, mais je n'avais pas encore regardé le log)

J'ai supprimé le fichier .lock qui était foireux, le script est reparti, il a traité 1000 caches, et cela a pris 800 secondes soit plus de deux fois 5 mn, le script a tenté de se relancer les deux fois, donc cela reste toujours d'actualité.

Du coup ce n'est pas sur que passer la durée à 30 heures règle le problème initial (même si c'est quand même beaucoup mieux)
Et de toutes façons si on s'oriente vers un cron indépendant de la durée de cache, on aura besoin d'un tel mécanisme

Pour éviter cela je vais rajouter un cron qui supprime le fichier .lock toutes les heures, ainsi le script peut recommencer à s'exécuter même en cas de non effacement du fichier .lock lors d'une exécution foireuse

je me suis aperçu qu'il y avait quelques enregistrements qui conservaient leur champ locked à 1

ce qui fait qu'ils ne sont jamais mis à jour par le cron je suppose

il y en avait très peu cela dit

j'ai passé à 0 en SQL

j'ai vu que tu avais prévu le coup avec la suppression des caches obsolètes en fin de script
en effet ces caches étaient à locked mais n'étaient pas assez "anciens" pour être détectés (maintenant qu'on est passé à 30h...)
au bout d'un certain temps ils auraient été supprimés par cette procédure

Les modifs ont été passées sur la prod chez nous

RESUME :

- le cron de mise à jour automatique du cache ne tourne plus que la nuit entre 22h et 6h
- Il tourne toutes les 10 mn (au lieu de toutes les 5 mn)
- Il crée un fichier .lock au démarrage et le supprime à la fin. Si le fichier .lock est toujours présent quand il démarre, il ne se lance pas. Un cron supprime toutefois ce fichier toutes les heures car parfois en cas de plantage du script, le fichier n'est pas détruit à la fin et le script ne se relance jamais.
- Il traite les 1000 plus vieux enregistrements, sans tenir compte de la durée de vie du cache spécifiée dans les paramètres.
- La durée de vie du cache a été passée à 30 heures (au lieu de 6 chez nous auparavant)

OBJECTIFS :

- Faire en sorte qu'à la connexion utilisateur, seul le cache soit utilisé (plus d'appel au Webservice à la connexion utilisateur)
- Parallèlement, faire en sorte que le cache soit le plus récent possible
- Alléger les ressources de la machine web durant la journée

La durée de vie du cache est vérifiée lors de la connexion utilisateur. Si elle est supérieure au paramètre, le webservice est appelé, sinon le cache est utilisé. Le paramètre de 30 heures combiné à la mise à jour des caches la nuit permet de toujours utiliser le cache à la connexion utilisateur, et ce dernier aura forcément moins de 24h durant la journée. Le pire cas étant un utilisateur qui se connecte en pleine nuit alors que son cache n'a pas été traité par le script.

En cas de cache obsolète (pour cause de plantage du script ou autre), la durée de 30h permet quand même de renouveler le cache dans un délai qui ne sera pas trop pénalisant pour l'utilisateur

Dans la plupart des cas, une nouvelle application "urgente" apparaîtra en cliquant "Shit-recharger". Nous communiquerons là-dessus.

CONSTAT :

- Le premier jour, on peut voir que tous les caches utilisateurs ont bien été mis à jour dans la nuit
- Le cron s'est bien déroulé de 22h à 6h
- Le cache est effectivement utilisé à chaque connexion (pour mon compte) ce qui allège le temps de chargement de 5s environ (21s sans cache --> 16s avec cache)

A SURVEILLER :

- Plusieurs enregistrements (765) étaient verrouillés ce matin (champ "locked" = 1). A priori c'est que le script ne les libère pas. Cela peut être problématique car du coup ils ne seront plus mis à jour. Ce verrouillage est mis en place pour éviter des mises à jour concurrentes en cas de multiples exécutions du script. Théoriquement c'est redondant avec le fichier .lock, mais je préfère le conserver pour le moment. J'ai supprimé les enregistrement concernés, mais si cela se reproduit, avant de le faire il faudra vérifier ces enregistrements par rapport au fichier .lock

- Quelques caches avaient été mis à jour après 6h. En théorie cela ne peut être qu'un shift-clic sur le bouton "rafraichir" (OU BIEN : une création d'une entrée qui n'existait pas)

Les enregistrements qui restaient verrouillés (locked = 1) étaient dus à un redémarrage des serveurs ARENA/RSA à 05h00 du matin qui faisait planter le script
Je fais terminer le cron à 05h00 car pour nous 7h suffisent largement à rafraîchir les caches des utilisateurs
Néanmoins il serait intéressant de prévoir une gestion d'erreur au cas ou... un délai de timeout du WS par exemple, qui interromprait la MAJ et basculerait sur l'enregistrement et le déverrouillage en cas de délai dépassé.
Cela dit ce n'est pas très grave dans la mesure ou les enregistrement verrouillés trop anciens sont nettoyés par le script. J'en laisse quelques uns pour vérifier que cela fonctionne bien

En revanche je remarque que ressources.php n'est plus que très rarement utilisé. Que ce soit en chargement simple (appel ou actualisation de la page web) ou en rechargement (bouton recharger sans le shift), ressources.php n'est pas appelé.

Il est appelé en revanche si l'on fait un shift+recharger (donc avec l'option ?reload=true et actualisation du cache ARENA)

J'en viens presque à me demander si la partie "gestion du cache" de ressources.php est encore utile car si ce fichier n'est appelé qu'avec l'option reload=true il est du coup inutile de tester la présence de cette option, ni de faire tout un tas de tests sur la durée de vie du cache...

Je me demande d'ailleurs comment le paramètre CACHE_DURATION est utilisé du coup... quel mécanisme lors du chargement du bureau détermine que le cache est obsolète ou pas ?

Je constate également qu'un mécanisme en background permet de rafraîchir le cache d'un utilisateur
Fonctionnement : au premier chargement, le bureau est chargé sans appel à ressources.php. Au bout d'un certain temps (à déterminer, variable ?), un appel en background à ressources.php (avec l'option reload=true) est fait, ce qui a pour effet de mettre à jour le cache de l'utilisateur.
C'est une bonne idée car cela permet de mettre à jour le cache sans faire attendre l'utilisateur. Je suppose que ce ce cache sera prêt lors de la prochaine connexion (ou prochain (re)chargement du bureau) de l'utilisateur.

Dans les logs de mon serveur de prod, je vois que ressources.php est très peu appelé (20% des appels du template). Je constate aussi qu'il reste encore appelé sans l'option reload=true, mais cela représente 30 % des chargements du fichier (et 5% des appels du template).

Je remarque aussi que le week-end, la proportion s'inverse : ressources.php est plus appelé sans l'option qu'avec. Le mercredi (moins de connectés) on constate aussi que sans s'inverser, l'écart se réduit.
En revanche la proportion d'appels de ressources.php par rapports aux chargements de bureau (appels du template) est toujours égale à 20%.

Je serais curieux de comprendre le mécanisme à l’œuvre.

Je continue à chercher

J'avais commencé une doc d'installation
Si tu es OK je la mets sur le WIki
Mais je ne sais pas si elle est suffisante ou pas

J'ai créé un document (pour conserver la mise en forme car c'était un document redmine chez nous)
Mais on dirait qu'il y a un pb sur le serveur car on voit bien le doc listé (avec un aperçu) mais si on clique sur le doc on obtient un 404...

https://dev-eole.ac-dijon.fr/projects/eole-dispatcher/documents

Sinon OK pour la réunion tel mardi 09 par contre GMT+4 c'est bien 08h-10h en métro ?

Puisque ça ne marchaot pas dans document, je l'ai créée comme page Wiki :
https://dev-eole.ac-dijon.fr/projects/eole-dispatcher/wiki/Installation_de_edispatcher

J'ai mis "NG" comme page parente et j'ai fait un lien vers la page concernée sur la page d'accueil

Pour revenir au cache, je viens de comprendre le mécanisme :
C'est un script situé dans ng/public/elements/elements.html qui charge (avec un délai de 10mn) un iframe sur le bureau avec l'option refresh

Sur le principe l'idée est bonne, ce n'est pas pénalisant au moment du chargement et ça permet de présenter un cache à jour à l'utilisateur à sa prochaine connexion

Toutefois je me permets 2 suggestions :
1) plutôt que d'ouvrir un frame sur le bureau (ce qui a pour inconvénient de recharger le template complet et l'ensemble des ressources), pourquoi ne ferait on pas un appel simplement à ressources.php ?
Le cache serait bien rechargé et il y aurait un seul appel réseau...
L'idéal serait même d'avoir un script séparé refreshcache.php qui ferait l'appel au WS et mettrait à jour le cache

2) Une fois le cache mis à jour, un truc top serait de lancer une comparaison entre les ressources présentes sur le bureau et les ressources du cache, et de recharger le bureau si on constate une différence
Ainsi, si une application a été ajoutée à un utilisateur, il la verrait immédiatement apparaître.
Ou bien faire apparaître un message "Une nouvelle application a été détectée : cliquez sur le bouton recharger pour la faire apparaître" ?

Ceci devrait faire l'objet d'une demande séparée car cela ne concerne pas le cron de la MAJ du cache

Pour revenir enfin à l'objectif premier de cette demande, je résume :

Est-ce qu'on valide que :

- le cron de mise à jour automatique du cache ne tourne plus que la nuit entre 22h et 5h (si validé, à changer dans le posttemplate je crois - ou postservice ?)

- Qu'il tourne toutes les 10 mn (au lieu de toutes les 5 mn) (idem)

- Qu'il crée un fichier .lock au démarrage et le supprime à la fin. Si le fichier .lock est toujours présent quand il démarre, il ne se lance pas. Un cron supprime toutefois ce fichier toutes les heures car parfois en cas de plantage du script, le fichier n'est pas détruit à la fin et le script ne se relance jamais.
(pour le fichier, si validé, je commite le changement, mais pour le cron il faudra ajouter au posttemplate)

- Il traite les 1000 plus vieux enregistrements, sans tenir compte de la durée de vie du cache spécifiée dans les paramètres. (si OK, je peux commiter le changement)

On en discutera lors de la réunion tel, mais c'était pour isoler et résumer les points spécifiques à cette demande très verbeuse (désolé)