Wir haben eine Kategorie #Ankündigungen, in der alle unsere Mitglieder automatisch angemeldet sind, um den ersten Beitrag zu verfolgen.
Dies ermöglicht es uns, die Veröffentlichung von Beiträgen in dieser Kategorie zu festgelegten Zeiten/Daten zu planen.
Die Ankündigung wird dann an rund 25.000 Mitglieder per E-Mail versendet.
Das Problem, mit dem wir konfrontiert sind, ist, dass der Versand der E-Mails über eine Stunde dauert, was für zeitkritische Ankündigungen nicht ideal ist.
Wenn ich Sidekiq beobachte, sehe ich, wie der Zähler „Geplant“ alle einzelnen E-Mails nacheinander hochzählt. Sobald er etwa 20.000 erreicht, verschiebt er sie in den Tab „Eingereiht“ und dann beginnen sie schließlich mit dem Versand.
Kann ich diesen Prozess irgendwie beschleunigen?
Für zeitkritische E-Mails wäre es schön, wenn sie etwa 100x schneller versendet würden als derzeit
Diese Diskussion könnte Ihnen helfen, da sie erklärt, wie DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE gesetzt wird, was das globale Limit für Digests definiert.
Verzögerung, während E-Mail-Jobs in die Warteschlange gestellt werden
Verarbeitungszeit für den Versand der eigentlichen E-Mail
Was das Erste betrifft, bin ich mir nicht zu 100 % sicher, aber ich glaube, dass eine Verringerung von email_time_window_mins dazu führt, dass die Benachrichtigungen früher in die Warteschlange gestellt werden.
Sobald die E-Mail-Jobs scheduled (geplant) sind, arbeiten Ihre Sidekiq-Worker sie nacheinander ab. Eine Erhöhung der Sidekiq-Worker (stellen Sie DISCOURSE_SIDEKIQ_WORKERS von 5 auf 10, 15 oder 20 ein, je nach Serverkapazität) bedeutet, dass mehr Jobs gleichzeitig verarbeitet werden, sodass die Warteschlange 2x/3x/4x schneller geleert wird.
Ich weiß zwar nicht im Detail, wie das Backend funktioniert, aber email_time_window_mins ist nur eine Verzögerungseinstellung, bevor die erste E-Mail gesendet wird. Während dieser Zeit kann jeder Benutzer, der so eingestellt ist, die E-Mail zu erhalten, die E-Mail „verfallen lassen“, wenn er zufällig innerhalb des Zeitfensters aktiv ist (offizielle Terminologie: E-Mail übersprungen; Überspringgrund: Benutzer wurde kürzlich gesehen).
Die Standardverzögerung beträgt 10 Minuten, d. h. der Beitrag muss 10 Minuten lang live sein, und erst dann werden die E-Mails gesendet.
Richies Problem ist die Zeitdifferenz zwischen der ersten und der letzten E-Mail… eine Verzögerung von einer Stunde. Dies liegt wahrscheinlich an der schieren Menge der zu sendenden E-Mails, obwohl ich auch hier keine Gewissheit habe.
Das Ändern der obigen Einstellung würde nur das Senden der ersten E-Mail beschleunigen, aber nicht die Dauer der gesamten Charge von 22.000 E-Mails bis zum Abschluss beheben.
Was wäre die empfohlene Einstellung, offensichtlich abhängig von der Infrastrukturfähigkeit?
Könnte eine hohe Einstellung zu Serverproblemen in Bezug auf Last oder anderes führen?
Es hängt zu 100 % von der Serverkapazität des OP ab – zu viele und es wird langsamer, zu wenige und es dauert länger, bis die Verarbeitung abgeschlossen ist.
Angesichts dessen, dass die CPU-Auslastung 40 % erreicht (ist das von einer einzelnen CPU oder der Gesamtkapazität?), würde ich wahrscheinlich damit beginnen, sie entweder um das 2-fache (konservativ) oder 3-fache (aggressiv) zu erhöhen und zu sehen, was passiert, abhängig von der Risikobereitschaft für Verlangsamungen.
Kann mir jemand bestätigen, dass dies die richtige Änderung ist, die ich an meiner app.yml vornehmen soll, wenn der Parameter DISCOURSE_SIDEKIQ_WORKERS derzeit nicht vorhanden ist?
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Wie viele gleichzeitige Webanfragen werden unterstützt? Hängt vom Arbeitsspeicher und den CPU-Kernen ab.
## wird automatisch von bootstrap basierend auf erkannten CPUs gesetzt, oder Sie können es überschreiben
UNICORN_WORKERS: 8
## Diese Zeile wurde am 04.10.25 hinzugefügt
## REF: https://meta.discourse.org/t/is-there-a-way-i-can-send-email-notifications-faster/383103/12
DISCOURSE_SIDEKIQ_WORKERS: 7
Ich werde später in der Woche einen Rebuild durchführen und die Zeit für den Versand von E-Mails messen
Nur damit ich weiß, dass meine Änderung wirksam geworden ist: Habe ich richtig gedacht, dass dieser Threads-Wert von 5 auf 7 steigen sollte?
Es schränkt sich nicht per se selbst ein, aber jeder Sidekiq-Worker verarbeitet einen Job nach dem anderen. Wenn also 22.000 E-Mails darauf warten, versendet zu werden, werden sieben davon gleichzeitig verarbeitet.
Was die lächerliche Seite der Dinge angeht, wird der Server wahrscheinlich nicht mithalten können, wenn Sie die Anzahl auf 1000 parallele Worker einstellen. Es geht also darum, eine Zahl zu finden, die all Ihren Bedürfnissen entspricht:
so viele Jobs wie möglich gleichzeitig verarbeiten, um die 22.000 E-Mails schneller zu versenden
aber nicht ALLE Serverressourcen beanspruchen, sodass keine mehr für die Benutzer der Website übrig bleiben
