Nous avons une catégorie #Announcements dans laquelle tous nos membres sont automatiquement abonnés pour suivre le premier message.
Cela nous permet de planifier la publication de messages dans cette catégorie à des heures/dates définies.
À son tour, l’annonce est ensuite envoyée par e-mail à environ 25 000 membres.
Le problème que nous rencontrons est que les e-mails mettent plus d’une heure à être envoyés, ce qui n’est pas idéal pour les annonces critiques en termes de temps.
Si je surveille Sidekiq, je peux voir le compteur « Scheduled » accumuler tous les e-mails individuels un par un. Une fois qu’il atteint environ 20 000, il les déplace vers l’onglet « Enqueued », puis ils commencent finalement à être envoyés.
Puis-je accélérer ce processus ?
Pour les e-mails critiques en termes de temps, ce serait bien de les envoyer environ 100 fois plus vite qu’ils ne le font actuellement
Cette discussion pourrait vous aider, car elle explique comment définir DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE, qui définit la limite globale pour les résumés.
délai pendant que les tâches d’e-mail sont mises en file d’attente
temps de traitement pour l’envoi de l’e-mail réel
Pour la première, je ne suis pas sûr à 100 % mais je pense que réduire email_time_window_mins signifie que les notifications sont mises en file d’attente plus tôt.
Une fois que les tâches d’e-mail sont planifiées, vos workers sidekiq les traitent une par une. Augmenter le nombre de workers sidekiq (définir DISCOURSE_SIDEKIQ_WORKERS de 5 à 10, 15 ou 20 selon la capacité du serveur) signifie que plus de tâches sont traitées en même temps, de sorte que la file d’attente est vidée 2x/3x/4x plus rapidement.
Je ne connais pas le fonctionnement du backend dans les moindres détails, mais email_time_window_mins est juste un réglage de délai avant que le premier e-mail ne soit envoyé. Pendant ce temps, tout utilisateur défini pour recevoir l’e-mail peut “renoncer” à l’e-mail s’il est actif pendant la fenêtre de période (terminologie officielle : e-mail ignoré ; raison de l’ignorance : L’utilisateur a été vu récemment).
Le délai par défaut est de 10 minutes, ce qui signifie que le message doit être publié pendant 10 minutes, et seulement ensuite les e-mails seront envoyés.
Le problème de Richie est la différence de temps entre le premier e-mail et le dernier e-mail… un délai d’une heure. C’est probablement dû à la grande quantité d’e-mails à envoyer, bien que je ne puisse pas non plus le dire avec certitude.
Changer le réglage ci-dessus ne ferait qu’accélérer l’envoi du premier e-mail, mais n’aborderait pas la durée d’achèvement du lot entier de 22 000 e-mails.
Quel serait le réglage recommandé, évidemment dépendant de la capacité de l’infrastructure ?
Un réglage élevé pourrait-il entraîner des problèmes de serveur en termes de charge ou autres ?
Cela dépend à 100 % de la capacité du serveur de l’OP : trop nombreux et cela ralentira les choses, trop peu et cela prendra plus de temps à traiter.
Étant donné que le graphique du processeur atteint 40 % (est-ce d’un seul processeur ou de la capacité totale ?), je commencerais probablement par augmenter soit de 2 × (conservateur), soit de 3 × (agressif) et je verrais ce qui se passe, en fonction de la tolérance au risque de ralentissement.
Quelqu’un peut-il confirmer que c’est le changement correct à apporter à mon app.yml lorsque le paramètre DISCOURSE_SIDEKIQ_WORKERS n’existe pas actuellement ?
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Combien de requêtes web simultanées sont prises en charge ? Dépend de la mémoire et des cœurs de processeur.
## sera défini automatiquement par le bootstrap en fonction des CPU détectés, ou vous pouvez le remplacer
UNICORN_WORKERS: 8
## Ajouté cette ligne le 04/10/25
## REF: https://meta.discourse.org/t/is-there-a-way-i-can-send-email-notifications-faster/383103/12
DISCOURSE_SIDEKIQ_WORKERS: 7
Je reconstruirai plus tard dans la semaine et chronométrerai l’envoi des e-mails
Juste pour savoir si mon changement a pris effet, est-ce que je pense correctement que cette valeur Threads devrait passer de 5 à 7 ?
Il ne se limite pas en soi, mais chaque worker sidekiq traitera une tâche à la fois. Ainsi, si vous avez 22 000 e-mails en attente, sept d’entre eux seront traités simultanément.
Pour être plus précis, le serveur ne pourra probablement pas suivre si vous définissez le nombre à 1000 workers parallèles. Il s’agit donc de trouver un nombre qui convienne à tous vos besoins :
traiter autant de tâches que possible en même temps pour traiter les 22 000 e-mails plus rapidement
mais ne pas utiliser TOUTES les ressources du serveur, ce qui n’en laisserait aucune pour les utilisateurs du site
