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…
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…
Yes - it looks like we need to define the --batch and --limit.
If I understand correctly, the batch should be:
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,