Thanks for checking the script!
Interesting - does mautic:broadcast:send also have a --limit parameter? Need to check. If so we can easily add it…
1 Like
Yes - it looks like we need to define the --batch and --limit.
If I understand correctly, the batch should be:
- 10 for SMTP
- 50 for mailjet since API v3
- etc.
This is the batch size - mails per call. With queuing, it will be pumped into the messenger_messages table and be no issue.
But without queue, we should set both parameters to useful numbers.
So if I run the queue each other minute, and have 14 mails / sec. and 40 loops to consume the queue… I may send up to 560 mails per cronjob run.
This means, I could set the broadcast command to 560 mails and batch them by 560 (if I wouldn’t want the queue to grow much more). But there is a reason there is the queue so we could load it a bit more and let the consumption run over time.
But true - we should also set the limit. Without queuing, the batch size needs to be adjusted to the service.
Do you agree?
This was the source, summarized by Perplexity:
Yes, the mautic:broadcasts:send command in Mautic offers both a --batch and a --limit parameter, although they are used differently in practice.
### --batch Parameter
The --batch parameter determines the number of emails sent in a single API call to the email service provider. This is particularly important because different email service providers have different limits for the number of emails per API call. For example, SparkPost allows up to 1000 emails per call, while SMTP typically only allows 10 emails per batch.
### --limit Parameter
The --limit parameter specifies how many contacts are processed per execution of the command. This means that during each execution of the command, a certain number of contacts are processed before the command is run again. The default value is 100 contacts per execution.
### Practical Use
In practice, the --batch parameter is used to control the number of emails sent in a single API call, while the --limit parameter controls the total number of contacts processed per execution. Both parameters can be used to optimize email sending and control server load.
Example of using both parameters:
bash* *php /path/to/mautic/bin/console mautic:broadcasts:send --batch=100 --limit=200* *
This command would process up to 200 contacts per execution and send 100 emails per API call.
It is important to note that the use of these parameters may vary depending on the version and configuration of Mautic. In some cases, the --limit parameter may not be explicitly supported, and instead, the --batch parameter is used to control the number of emails per API call.
Yes thats exactly how I understand it, too!
Last time I send a bigger segment mail I discovered and debugged this. I had a --batch defined but the broadcast still always used to send 100 mails per cronjob run. After researching a while, I found out what I wanted to achieve with the --batch arg was actually done with the --limit arg. I don’t see any default value for the --batch arg in the help command though. So I’m curious what happens when you only define the --limit. Is there a default value that is not documented or will it send it in one batch?
My current setup utilizes the queue system and your script.
My AWS SES limit is 19 mails/s.
In the .env I set EMAILS_PER_BATCH to 17 to have some buffer. (SES should support up to 50 per api call as far as I know?)
BROADCASTS_SEND_LIMIT is 1020 because my server should handle this.
So the MAX_LOOPS would be 60.
The only change I made was setting the --limit and --batch to the BROADCASTS_SEND_LIMIT value because I wanted to send in one batch. It seems to work fine, but it is not tested with a bigger segment mail yet (like 50k emails)
The script runs via supervisor, after the script finished there is a 2s delay, then it starts all over again…
With this config it should not go over the sending limit at all though. Especially since I also use ses etailors transport which probably has rate limiting in place already.
I can keep you posted if the next segment mail is sending like I expect it to.
Greetings,
1 Like
How does this work when using rabbitmq for the queue service?
how often do you set the cron job for?
I let it run every other minute.
Does this guide work on Mautic 5.2.2 and 5.2.3 ?
And will it be a standard feature of Mautic 6.x ?
Just a quick heads up here. Running the script with the etailors ses plugin was kinda spamming the amazon ses api, because whenever you consume the messages, the plugin will check your current account maxSendRate limit via api. It was fixed with a caching functionality (see Adding SES Api Call caching functionality. by BuggerSee · Pull Request #33 · pm-pmaas/etailors_amazon_ses · GitHub)
Also important to know is that the ses plugin will consume 1 DB queue entry every second. So you should not set the --batch higher than your maxSendRate else it will send faster than allowed.
I also put the actual consuming of messages in a separate supervisor thread for performance reasons and because the loop is not needed with the ses plugin + queue.
I don’t think I fully understood. Are you talking about the script in combination with symfony &
the plugin by pabloveintimilla?
What would need to be changed in the script? I’m happy to further improve it.
I didn’t run it with etailors.
Ah okay. No I was specifically talking about using the script in combination with the etailors ses plugin.
I dont use the plugin by pabloveintimilla, so I don’t know how it works to be honest.
But etailors’ plugin always fetched the amazon send rate everytime you call the consume command, so it was getting rate limited by the amazon api. (Because your script kinda calls it every second)
The pullrequest I linked earler fixed this issue with caching functionality though, so now your script is fully compatible with the etailors ses plugin, too!
Yes you can add it. Wrote this guide because my worker sometimes didn’t stopped and my server crashed regularly and is a very big server.
So the focus was specific for doctrine and to make sure the worker died when it should and no other worker could be triggered before the previous was first stopped.
Also, it should manage the broadcasts since mautic 5 using doctrine, all messages go to the temporary table before being sent and is the worker who manages the sending speed.
So the broadcast or the campaign trigger messages end in the same table, thus this script handles them the same.
rabbitmq as far as I know replaces doctrine, so I don’t really know, don’t have experience with that.
Any period you want, the lock mechanism in the file will prevent you creating new workers thus the sending speed will be always limited. I have it like at 5 minutes to fill gaps if the previous worker dies suddenly.
what version of mautic are you using?
Yes, that will send, if I remember correctly, the segment emails. Sort of. Will send them to the message_messages table to be then handled by the worker.
so far, yes