Revisando temas que preguntan sobre la limitación de velocidad/estrangulamiento de resúmenes y correos electrónicos, la única configuración disponible parece ser DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE.
No sé si debería asumir que el valor para eso se distribuye exactamente en una tasa de X por segundo.
Y solo son resúmenes; tendría que tener en cuenta otras oleadas como las ráfagas de “seguir la primera publicación”, etc.
Con la información que tengo, no parece viable usar un servicio SMTP con un límite de velocidad. ¿Hay algo tranquilizador que me haya perdido?
Sin tener una idea de cómo maneja Discourse al encontrarse con un límite de tasa, he pospuesto la migración a Emailit. Pero tengo la esperanza de saber cómo le va a Don con el cambio a Emailit.
La respuesta es no.
El trabajo que pone en cola los resúmenes se ejecuta cada 30 minutos, y todo lo que hace esta configuración es establecer un número máximo de max_digests_enqueued_per_30_mins_per_site en la cola. No controla la rapidez con la que se procesa la cola.
Por cierto, estoy viendo algunas críticas bastante malas para emailit recientemente, tanto en Trustpilot como en AppSumo.
Si tuviera que lidiar con esta situación, probablemente manejaría la complejidad entregando a una instancia local de postfix que pone el correo en cola.
Luego puede reenviar el correo directamente (intentaría primero directamente y luego recurriría a una alternativa) o a través de uno o más servicios de pago salientes.
Esto también aliviará la carga de su servidor, ya que la operación relativamente costosa de generar el correo electrónico solo ocurrirá una vez, no una y otra vez (si se limita la velocidad).