En examinant les sujets qui interrogent sur la limitation du débit/la limitation des résumés et des e-mails, le seul paramètre disponible semble être DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE.
Je ne sais pas si je dois supposer que la valeur de celui-ci est distribuée exactement en un taux X par seconde.
Et ce ne sont que les résumés – je devrais tenir compte d’autres pics comme les envois groupés de première publication suivie, etc.
Avec les informations dont je dispose, il ne semble pas réalisable d’utiliser un service SMTP avec une limite de débit. Y a-t-il quelque chose de rassurant que j’aurais manqué ?
Sans avoir une idée de la manière dont Discourse gère la rencontre d’une limite de débit, j’ai hésité à passer à Emailit. Mais j’espère avoir des nouvelles du passage de Don à Emailit (Awesome deal for SMTP! No more monthly fees (: - #21 by ToddZ).
La réponse est non.
Le travail qui met en file d’attente les résumés s’exécute toutes les 30 minutes, et ce paramètre ne fait que fixer un nombre maximum de max_digests_enqueued_per_30_mins_per_site dans la file d’attente. Il ne contrôle pas la vitesse à laquelle la file d’attente est traitée.
Au fait, je vois de très mauvaises critiques pour emailit récemment, à la fois sur Trustpilot et AppSumo.
Si je devais gérer cette situation, je gérerais probablement la complexité en livrant à une instance Postfix locale qui met les e-mails en file d’attente.
Elle peut ensuite transférer les e-mails soit directement (je lui ferais essayer directement en premier, puis revenir en secours) soit via un ou plusieurs services payants sortants.
Cela allégera également la charge de votre serveur puisque l’opération relativement coûteuse de génération de l’e-mail n’aura lieu qu’une seule fois, et non à plusieurs reprises (s’il est limité par le débit).