Does 30-minute digest rate setting divide precisely into a per-second rate?

Product Support

AI-generated summary

The discussion explores whether Discourse’s 30-minute digest rate setting translates precisely into a per-second email sending rate. ToddZ expresses concern about switching to Emailit’s plan, which enforces a 2 emails-per-second limit, and questions how Discourse handles rate limits. RGJ clarifies that the digest job runs every 30 minutes and the rate limit setting only controls the maximum number of emails queued, not a strict per-second distribution. This means the system does not distribute the digest rate evenly across seconds, so a per-second limit could be exceeded. ToddZ acknowledges this and decides to avoid relays with per-second limits. supermathie suggests using a local Postfix instance to manage outgoing mail and handle rate limits more effectively, allowing fallback to paid services if needed.

1

Continuing the discussion from Abiding by Amazon SES's "14 emails per second" maximum send rate:

I’ve been thinking of switching my SMTP relay to the generous Emailit plan of $20 per 100,000 messages, but they’ve recently set a rate limit of 2 emails per second.

Reviewing topics that ask about rate limiting / throttling digests and emails, the only available setting seems to be DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE.

I don’t know if I should assume that the value for that is distributed exactly into an X-per-second rate.

And it’s only digests – I’d have to account for other surges like watching-first-post blasts, etc.

With the info I have, it doesn’t feel workable to use an SMTP service with a rate limit. Is there anything reassuring that I’ve missed?

2

Hey Todd sorry to hear you had no takers for this topic. Were you able to figure it out?

4

Without some idea of how Discourse handles running into a rate limit, I’ve held off on moving to Emailit. But I’m hoping to hear how Don’s switch to Emailit goes.

5

The answer is no.

The job that enqueues digests runs every 30 minutes, and all this setting does is put a maximum number of max_digests_enqueued_per_30_mins_per_site in the queue. It does not control how quickly the queue is processed.

BTW Seeing some pretty bad reviews for emailit recently, both on trustpilot and appsumo.

6

Thank you for the info, Richard! Sounds like I want to avoid a relay with a per-second rate limit.

(I may look into Zoho’s Zeptomail at $2.50 per 10,000 emails. Some folks here report success with that.)

7

Were I to have to deal with this situation I would probably handle the complexity by delivering to a local postfix instance that queues mail.

It can then forward mail either directly (I would have it try direct first, and fall back) or via one or more outbound paid services.

You can also manage its outbound rate: Postfix Configuration Parameters

This will also ease the burden on your server since the relatively expensive operation of generating the email will only happen once, not over and over (if it gets rate limited).