More accurate email rate limiting
What does this MR do?
Improve rate limiting to ignore bouncing mails and take care of multiple recipients per mail to make it more accurate.
Current rate limiting in postfix only allows us to theoretically 60 mails per second which turns out to only be ~47 in reality as you can see here.
In this Slack discussion we set our rate limit with a quickfix to to 40 mails / minute to help dequeue the previous large queue and move this queue to redis. As this is only a very basic rate limiting this number of 40 mails per second is around ~36 in relity.
I'm guessing this queue which isn't represented by a graph anymore/yet is growing daily.
This MR changes the php rate limiting to hopefully make it more accurate and raises the number to 45,11 mails/minute which is slightly below the postfix reality limit. This change will only become active in production and thus must be hotfixed after having it in master.
How confident are you it won't break things if deployed?
Quite
Links to related issues
How to test
Steps a reviewer can take to verify that this MR does what it says it does e.g.
You can't really test it locally as it is highly dependend on the speed and circumstances of the server.
Screenshots (if applicable)
Not possible. Backend change.
Checklist
-
added a test, or explain why one is not needed/possible... -
no unrelated changes -
asked someone for a code review -
joined #foodsharing-beta channel at https://slackin.yunity.org -
added an entry to CHANGELOG.md (description, merge request link, username(s)) -
Once your MR has been merged, you are responsible to update the #foodsharing-beta Slack channel about what has been changed here. They will test your work in different browsers, roles or other settings