Accélérer la récupération du statut "jobs are old" d'un cluster #184
Conversation
…if cluster jobs are old. Much faster to use than get_jobs().
|
Moi, ça me va comme PR. Notons qu'on aurait intérêt à plus moyen terme à mettre en place une autre solution qui calcule périodiquement cela (comme un petit poisson qui lèche les parois de l'aquarium pour les nettoyer) et qui met la valeur dans une "cache" pour éviter de recalculer ça chaque fois que qqun ouvre une page. Ça me semble excessif de faire 4-5 requêtes à MongoDB à chaque chargement de page (comme fait cette PR), mais c'est vraiment mieux que la situation actuelle. Vu qu'on est dans une situation où la version en "prod" est très affectée par les ralentissements causés par ces requêtes sur des listes complètes de jobs, et qu'on remédier à la situation au plus vite, je suis en faveur de passer cette PR et de demander à l'équipe d'Infra de la déployer. La prochaine étape, où ces valeurs seront calculées une fois par jour, viendra plus tard et sera gérée séparément. |
|
Par ailleurs, je pense que le choix de 30 jours comme délais est trop long. Il faut penser à combien de temps on aimerait laisser s'écouler avant de signaler à quelqu'un qu'une grappe n'est plus vraiment mise à jour. Je pense qu'on devrait mettre une valeur qui ressemble davantage à "2 jours" au lieu de "30 jours". L'inconvénient est qu'on pourrait accidentellement laisser croire à des gens qu'une grappe n'est plus accessible par Clockwork, alors qu'elle en bon état mais sans jobs récentes. Tout cela renforce la perspective comme quoi cette mesure de "est-ce que telle grappe est bien 'scrapée' ?" devrait être calculée de manière externe, possiblement par le script qui fait le scraping tout simplement. Le script qui fait le scraping peut facilement voir si des jobs ont été lues, si sa commande a réussi. L'idée d'inférer le succès de manière indirecte en regardant la job la plus récente était peut-être une mauvaise approche. Au minimum, donc, il faudrait mettre le chiffre plus bas que 30. Disons 2. Ensuite, il faudrait repenser à comment on gère cette feature visuelle qui signifie quelles grappes sont potentiellement mal renseignées. |
|
Oui, change le délais de 30 jours pour 2 jours, svp, et comme ça Soline pourra merger quand elle sera satisfaite. |
Salut, @soline-b ! Voici la PR contenant la petite optimisation dont on parlait concernant la récupération du statut d'un cluster !