Add support for configurable dequeue size #3031
Conversation
When sending messages to remote MTAs, the messages get dequeued in batches from the local queue. As the batch-key is the given remote MX server, those messages will be delivered to this remote MTA in one SMTP session. Although this is good for performance (to reuse the same SMTP session for many mails), many of the real-world MTAs do not like sending too much mails at once in one single session. Example error messages are similar to "421 too many messages in this connection" Therefore, we make the limit adjustable (with the default value of 100 to be backwards compatible). From our experiences with the last 5 million emails sent, having a batch size of 10 works almost ever, and 50 seems to be the upper "real world" limit before hitting those rate limits by the remote MTAs.
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
Can we get this merged? :) |
|
Is this possibly a solution for https://github.com/orgs/postalserver/discussions/2917 ? |
Yeah, most likely yes. |
|
Since we're running the patched version of postal with the batch_queue_messages_limit set to 10 in our own infrastructure, we never had any of those messages mentioned in https://github.com/orgs/postalserver/discussions/2917 (we had many of those before, running with the default size of 100). |
|
Asi Iam not a developer :-) How can I apply this patch on my postal server in the easiest way? Many thanks at @schueffi for the commit |
When sending messages to remote MTAs, the messages get dequeued in batches from the local queue. As the batch-key is the given remote MX server, those messages will be delivered to this remote MTA in one SMTP session. Although this is good for performance (to reuse the same SMTP session for many mails), many of the real-world MTAs do not like sending too much mails at once in one single session.
Example error messages are similar to "421 too many messages in this connection"
Therefore, we make the limit adjustable (with the default value of 100 to be backwards compatible). From our experiences with the last 5 million emails sent, having a batch size of 10 works almost ever, and 50 seems to be the upper "real world" limit before hitting those rate limits by the remote MTAs.