The emails are sent, but with the above settings the table messenger_messages keeps filling up. I have not found any documentation on this, but I suppose that the emails that are “sent” by the cron command are actually pushed, images and all, into this table and the messenger:consume command is supposed to read and process (e.g. send to SMTP provider) them from there.
What happens is that the table will, in the course of 1-2 hours, grow about 60GB and then everything crashes because space is full. I will have to manually clear and optimize the table to make it work again.
I suppose that my workflow is fine but that the settings are faulty. I have tried multiple workers with no effect. Also, I can’t find a way to actually log how many emails are processed by a worker.
When I put it very small values (like 100 emails every five minutes), this doesn’t happen and everything gets sent just fine. But then sending the daily newsletter will take about 40 hours.
If you read this far, please consider commenting. Any idea will help Thanks
You specified, that your job runs up to 1h or up to 700 pieces of mail. Depending on how you set it up, at the same time you start 11 other instances of your cronjob (each 5 min right?). Maybe you run into trouble with your STMP interface (rate limit?).
I set up the cronjob to send 700 emails per 4 minutes. I set up the systemd service to consume emails continuously, but I don’t know how to find out its processing speed.
My SMTP provider will allow me to send 200.000 emails per hour. I intend to send 50.000 emails per day.
My VM has 16GB RAM and 4 vCPUs that are never, even during sending, using more than one third of capacity.
Do you know a way to discover how many emails are processed by the messenger:consume job? I understand that I need to balance the settings with my hardware, but I don’t know how.
I also think that your hardware looks decently sized…
You probably could start issuing the commands on your server shell and track times. Maybe enhance a script with some output to console to see the progress. You may then identify the bottleneck.
With my script I quickly found out, that it already took more than a second to send those 14 mails and I won’t hit the rate limit this way…