Ceci est surtout à titre informatif, et peut-être même trop d’informations, mais cela pourrait vous aider, ne serait-ce que légèrement, à mieux comprendre certains des phénomènes intéressants que nous rencontrons en exécutant trois conteneurs simultanément (deux pour l’application web et un pour les données), ainsi que l’impact sur les avatars des utilisateurs.
Il est très intéressant (et, à mon avis, très cool) de voir comment le planificateur de tâches Redis / Sidekiq fonctionne lorsqu’ils s’exécutent en parallèle, mais qu’un seul est « actif du côté web de l’utilisateur » :
J’espère que vous trouverez cette brève discussion, illustrée par un exemple concret, intéressante. Elle pourrait vous apporter un peu de lumière sur le planificateur de tâches de Discourse, l’optimisation des images et les avatars, selon notre configuration :
Je suis un grand admirateur de la façon dont Discourse utilise Redis / Sidekiq pour planifier les tâches en arrière-plan ; je considère cela comme l’une des forces et des avantages clés de l’architecture logicielle de Discourse.
Note : Ces concepts s’appliquent également, de diverses manières subtiles, aux différentes étapes du processus de sauvegarde et de restauration, ainsi qu’à d’autres processus dépendants du temps. Il est donc judicieux de comprendre comment et pourquoi Sidekiq planifie les tâches en arrière-plan.