Abbiamo una categoria #Announcements in cui tutti i nostri membri sono automaticamente iscritti per seguire il primo post.
Ciò ci consente di pianificare la pubblicazione dei post in quella categoria in orari/date prestabilite.
A sua volta, l’annuncio viene inviato via email a circa 25.000 membri.
Il problema che affrontiamo è che le email impiegano oltre un’ora per essere inviate, il che non è ideale per annunci critici in termini di tempo.
Se monitoro Sidekiq, posso vedere il contatore “Scheduled” accumulare tutte le singole email una per una, una volta raggiunto circa 20.000, le sposta nella scheda “Enqueued”, e poi alla fine iniziano a essere inviate.
C’è un modo per velocizzare questo processo?
Per le email critiche in termini di tempo, sarebbe bello inviarle circa 100 volte più velocemente di quanto facciano attualmente
Questa discussione potrebbe esserti d’aiuto, poiché spiega come impostare DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE, che definisce il limite globale per i digest.
ritardo durante l’accodamento dei processi di posta elettronica
tempo di elaborazione per l’invio dell’email effettiva
Per il primo, non sono sicuro al 100%, ma penso che ridurre email_time_window_mins significhi che le notifiche vengono accodate prima.
Una volta che i processi di posta elettronica sono scheduled, i tuoi worker sidekiq li elaborano uno alla volta. Aumentare i worker sidekiq (imposta DISCOURSE_SIDEKIQ_WORKERS da 5 a 10, 15 o 20 a seconda della capacità del server) significa che più processi vengono elaborati contemporaneamente, quindi la coda viene svuotata 2x/3x/4x più velocemente.
Non so come funzioni il backend nei minimi dettagli, ma email_time_window_mins è solo un’impostazione di ritardo prima che venga inviata la prima email. Durante questo periodo, qualsiasi utente impostato per ricevere l’email può “rinunciare” all’email se dovesse essere attivo entro la finestra temporale (terminologia ufficiale: email saltata; motivo del salto: L’utente è stato visto di recente).
Il ritardo predefinito è di 10 minuti, il che significa che il post deve essere attivo per 10 minuti, e solo allora verranno inviate le email.
Il problema di Richie è la differenza di tempo tra la prima email e l’ultima email… un ritardo di un’ora. Questo è probabilmente dovuto alla grande quantità di email che devono essere inviate, anche se non posso dirlo con certezza.
Modificare l’impostazione sopra citata accelererebbe solo l’invio della prima email, ma non risolverebbe la durata del completamento dell’intero batch di 22.000 email.
Quale sarebbe l’impostazione consigliata, ovviamente dipendente dalla capacità dell’infrastruttura?
Un’impostazione elevata potrebbe causare problemi al server in termini di carico o altro?
Dipende al 100% dalla capacità del server dell’OP: troppi rallenteranno le cose, troppo pochi richiederanno più tempo per l’elaborazione.
Dato che il grafico della CPU raggiunge il 40% (è di una singola CPU o della capacità totale?), probabilmente inizierei aumentando di 2 volte (conservativo) o 3 volte (aggressivo) e vedrei cosa succede, a seconda della tolleranza al rischio di rallentamenti.
Qualcuno è in grado di confermare che questa è la modifica corretta da apportare al mio app.yml quando il parametro DISCOURSE_SIDEKIQ_WORKERS non esiste attualmente?
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Quante richieste web concorrenti sono supportate? Dipende dalla memoria e dai core della CPU.
## verrà impostato automaticamente da bootstrap in base alle CPU rilevate, oppure puoi sovrascriverlo
UNICORN_WORKERS: 8
## Aggiunta questa riga il 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
Ricostruirò più tardi questa settimana e cronometrerò l’invio delle email
Solo per sapere se la mia modifica ha avuto effetto, ho capito bene che questo valore Threads dovrebbe aumentare da 5 a 7?
Non si sta limitando di per sé, ma ogni worker di sidekiq elaborerà un’attività alla volta, quindi se hai 22000 email in attesa di essere inviate, sette di esse verranno elaborate contemporaneamente.
Per quanto riguarda le cose ridicole, il server probabilmente non sarà in grado di tenere il passo se imposti il numero a 1000 worker paralleli. Quindi si tratta di trovare un numero che soddisfi tutte le tue esigenze:
elaborare il maggior numero possibile di attività contemporaneamente per smaltire più velocemente le 22000 email
ma non occupare TUTTE le risorse del server, lasciandone nessuna per gli utenti del sito
