Bonjour, tout d’abord, merci beaucoup pour la nouvelle interface d’administration du sondage RSS. La différence est notable !
Nous avons un site web avec des dizaines de flux RSS. J’ai remarqué dans Sidekiq que certains jobs pour certains flux peuvent prendre vingt minutes ou plus. Cela encombre facilement la file d’attente.
Il existe un paramètre Délai d'expiration de la requête du flux RSS (RSS polling feed request timeout), mais ce n’est pas le problème. Le flux RSS est rapidement disponible et se charge vite (du moins lorsque j’essaie avec mon navigateur en même temps que Sidekiq a du mal avec le même flux). Le problème semble être que certains flux RSS contiennent tous les épisodes d’un podcast (au lieu des 10 à 15 plus récents) et que Discourse semble traiter toutes ces entrées, même si les épisodes ont déjà été téléchargés et qu’il n’y a pas de modifications. En gros, Sidekiq peut facilement être en difficulté pendant une demi-heure ou plus à cause de flux RSS qui n’apportent aucun changement, aucun nouvel épisode.
Idéalement, Discourse devrait rapidement constater qu’il n’y a pas de changements et passer à autre chose.
Optionnellement, il pourrait y avoir un paramètre pour limiter la lecture aux NN premières entrées du flux.
Ou, à tout le moins, une limite de temps pour mettre fin à un sondage s’il n’est pas résolu après NN minutes (5 minutes, ou 10 au maximum).
Je me demande exactement ce qui se passe lorsqu’un flux prend plus de 10 minutes à être traité et que Sidekiq est à 100 % de sa capacité. Qu’est-ce qui peut exactement prendre autant de temps et être si lourd à traiter ?
Pensez-vous que c’est quelque chose qui pourrait être amélioré dans le plugin actuel ?
Je serais ravi d’améliorer cela. Pourrais-tu partager l’URL de ton flux afin que je puisse mieux tester localement ? (N’hésite pas à m’envoyer un message privé si tu souhaites garder cela confidentiel)
Merci beaucoup @zogstrip pour ta réponse rapide ! Les flux RSS sont publics et sont d’ailleurs recommandés pour quiconque aime écouter des podcasts et des émissions de radio en espagnol de manière indépendante.
Beaucoup d’entre eux utilisent WordPress et nous pouvons leur demander de modifier le nombre d’entrées dans leur flux RSS. Mais beaucoup utilisent iVoox, une plateforme populaire au moins dans les pays hispanophones. Ils incluent tous les épisodes d’un programme dans leur flux RSS, c’est une entreprise (relativement) importante, et il est difficile de même trouver un lien « Contactez-nous » qui mène à une personne. Nous sommes donc bloqués là. Pour ton test, je commencerais par ajouter les flux iVoox, puis on en ajouterait d’autres si tu en veux plus.
Je suis très heureux de notre petite contribution à la signalisation de ce problème. Même si notre cas est assez particulier (je suppose ?), la solution contribuera, à un moindre degré, à la performance de pratiquement toute instance Discourse utilisant ce plugin.
Je vois que les correctifs ont été fusionnés. Cela signifie-t-il que nous pouvons les obtenir en mettant à jour Discourse maintenant ?
« Merged » signifie que les modifications sont dans la branche main. En général, les forums ne suivent pas la branche principale ; ils suivent plutôt la branche latest. Cela signifie qu’après la fusion, vous devez encore attendre que les tests automatiques s’exécutent et réussissent.
En consultant Commits · discourse/discourse · GitHub, vous pouvez voir que cela vient de se produire avec les commits de zogstrip (il y a une coche verte, tandis que le commit au-dessus a toujours un point marron).
J’ai réactivé les flux RSS et la première passe de traitement s’est globalement bien déroulée. 86 nouveaux articles sont apparus, dont beaucoup datant de plusieurs jours, ce qui signifie que plusieurs flux n’avaient pas pu terminer leur traitement auparavant, mais que c’est désormais le cas. Très bon signe !
Les flux très longs peuvent encore occuper un processus pendant une longue période, mais je n’en ai vu que trois dépasser les 10 minutes. Celui-ci est toujours en cours après une heure… Mais il est vraiment très long, donc peut-être que c’est justifié ? D’un autre côté, le fait qu’un seul flux occupe un processus si longtemps pose déjà problème en soi. Cela tient-il au fait qu’il s’agit du premier import complet depuis un certain temps ? Je vérifierai à nouveau lors du prochain cycle RSS (nous l’avons configuré sur 180 minutes).
Peut-être que cette tâche, qui tourne depuis une heure, est bloquée sur quelque chose au-delà de l’import ? Je viens de remarquer que tous les articles de ce flux semblent avoir été importés, images comprises. Du point de vue de l’utilisateur, l’import semble terminé. C’est peut-être un cas isolé. Je ferai un nouveau retour après quelques autres cycles RSS.
Ces flux sont-ils « nouveaux » ou ont-ils tous déjà été importés ? Je n’ai pas fait beaucoup de progrès concernant l’amélioration de la vitesse de l’import initial, car cela est largement limité par la rapidité avec laquelle nous pouvons créer de nouveaux sujets.
D’accord, nous avons modifié la fréquence de vérification à 10 minutes à des fins de test (nous la ramènerons à 180 minutes, ce qui nous convient très bien). Après la correction de zogstrip, la plupart des flux sont traités en moins d’une minute. Il n’y a que quelques flux très longs qui peuvent prendre jusqu’à 2 minutes ou plus, mais jamais (à ma connaissance) plus de 5 minutes. Ce flux RSS est le seul qui met régulièrement 4 minutes ou plus, mais il est extrêmement long, donc je ne suis pas sûr qu’on puisse faire grand-chose dans ce cas. Même le navigateur met du temps juste à l’afficher. (Et nous pourrions le supprimer pour des raisons non liées.)
Le fait que tout le processus de vérification ne prenne pas plus de 5 à 6 minutes est impressionnant. Une énorme amélioration. Pour moi, ce rapport peut être clos. Merci beaucoup encore, @zogstrip.
