Tenemos una categoría #Announcements en la que todos nuestros miembros están suscritos automáticamente para ver la primera publicación.
Esto nos permite programar la publicación de entradas en esa categoría en momentos/fechas determinadas.
A su vez, el anuncio se envía por correo electrónico a unos 25.000 miembros.
El problema que tenemos es que los correos electrónicos tardan más de una hora en enviarse, lo que no es ideal para anuncios críticos en cuanto al tiempo.
Si observo Sidekiq, puedo ver que el contador “Scheduled” acumula todos los correos electrónicos individuales uno por uno; una vez que llega a unos 20.000, los traslada a la pestaña “Enqueued” y, finalmente, comienzan a enviarse.
¿Hay alguna forma de acelerar este proceso?
Para correos electrónicos críticos en cuanto al tiempo, sería bueno enviarlos unas 100 veces más rápido de lo que van actualmente
Esta discusión puede ayudarte, ya que explica cómo establecer DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE, que define el límite global para los resúmenes.
retraso mientras se ponen en cola los trabajos de correo electrónico
tiempo de procesamiento para enviar el correo electrónico real
Para lo primero, no estoy 100% seguro de esto, pero creo que reducir email_time_window_mins significa que las notificaciones se ponen en cola antes.
Una vez que los trabajos de correo electrónico están programados, sus trabajadores de sidekiq los procesan uno a la vez. Aumentar los trabajadores de sidekiq (establecer DISCOURSE_SIDEKIQ_WORKERS de 5 a 10, 15 o 20 según la capacidad del servidor) significa que se procesan más trabajos al mismo tiempo, por lo que la cola se vacía 2x/3x/4x más rápido.
No sé cómo funciona el backend con el mayor detalle, pero email_time_window_mins es solo una configuración de retraso antes de que salga el primer correo electrónico. Durante este tiempo, cualquier usuario que esté configurado para recibir el correo electrónico puede “renunciar” al correo electrónico si resulta estar activo dentro de la ventana de período (terminología oficial: correo electrónico omitido; motivo de omisión: El usuario fue visto recientemente).
El retraso predeterminado es de 10 minutos, lo que significa que la publicación debe estar activa durante 10 minutos y solo entonces se enviarán los correos electrónicos.
El problema de Richie es la diferencia de tiempo entre el primer correo electrónico y el último… un retraso de una hora. Esto se debe probablemente a la gran cantidad de correos electrónicos que deben enviarse, aunque tampoco puedo decirlo con certeza.
Cambiar la configuración anterior solo aceleraría el envío del primer correo electrónico, pero no abordaría la duración de finalización del lote completo de 22.000 correos electrónicos.
¿Cuál sería la configuración recomendada, obviamente dependiente de la capacidad de la infraestructura?
¿Podría una configuración alta resultar en problemas del servidor en términos de carga u otros?
Depende al 100% de la capacidad del servidor del OP: demasiados y ralentizará las cosas, muy pocos y tardará más en procesarse.
Dado que el gráfico de la CPU alcanza el 40% (¿es de una sola CPU o de la capacidad total?), probablemente comenzaría aumentando 2 veces (conservador) o 3 veces (agresivo) y vería qué sucede, dependiendo de la tolerancia al riesgo de ralentizaciones.
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## ¿Cuántas solicitudes web concurrentes se admiten? Depende de la memoria y los núcleos de CPU.
## se establecerá automáticamente mediante bootstrap según las CPU detectadas, o puede anularlo
UNICORN_WORKERS: 8
## Añadí esta línea el 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
Reconstruiré más adelante esta semana y cronometraré el envío de correos electrónicos
Solo para saber si mi cambio ha surtido efecto, ¿estoy en lo cierto al pensar que este valor Threads debería aumentar de 5 a 7?
No se limita por sí mismo, sino que cada trabajador de sidekiq procesará un trabajo a la vez, por lo que si tienes 22000 correos electrónicos esperando para ser enviados, siete de ellos se procesarán a la vez.
En el lado ridículo de las cosas, el servidor probablemente no podrá seguir el ritmo si estableces el número en 1000 trabajadores paralelos. Así que se trata de encontrar un número que se adapte a todas tus necesidades:
procesar tantos trabajos como sea posible al mismo tiempo para poder enviar los 22000 correos electrónicos más rápido
pero no consumir TODOS los recursos del servidor, lo que dejaría ninguno para los usuarios del sitio
