BULK_MAILS_PER_CYCLE Not working as expected.

[TDBF]

I have set the constant BULK_MAILS_PER_CYCLE to 100, however bulk emails are still being sent out at 400 a time.

\define( 'BULK_MAILS_PER_CYCLE', 100 );

Thus my emails are getting temporarily deferred due to unexpected volume.

Is this correct or am I missing something here? 🙂

[Stuart Silvester]

1 hour ago, TDBF said:

I have set the constant BULK_MAILS_PER_CYCLE to 100, however bulk emails are still being sent out at 400 a time.

\define( 'BULK_MAILS_PER_CYCLE', 100 );

Thus my emails are getting temporarily deferred due to unexpected volume.

Is this correct or am I missing something here? 🙂

This constant doesn't affect the speed at which emails are sent, only the amount that are processed 'per cycle' and background tasks are designed to run as many cycles as possible in within the allowed server resources.

There isn't a way to restrict how many emails are sent per time, perhaps you may want to look at a service such as SendGrid or SES that can handle the volume.

[TDBF]

2 hours ago, Stuart Silvester said:

This constant doesn't affect the speed at which emails are sent, only the amount that are processed 'per cycle' and background tasks are designed to run as many cycles as possible in within the allowed server resources.

There isn't a way to restrict how many emails are sent per time, perhaps you may want to look at a service such as SendGrid or SES that can handle the volume.

Thanks for the info.

There was only 700+ emails being sent out in total, shame you couldn't put a time on each cycle 😉

I have already been looking into SendGrind, but it's not really worth it as we only do bulk emails once every blue moon.

Thanks.

[opentype]

On 9/29/2021 at 11:53 PM, Stuart Silvester said:

background tasks are designed to run as many cycles as possible in within the allowed server resources

How is that calculated? I too would like to get a better understanding of how the cycle variable would typically affect the time distributions of the mails. At least roughly. 

[Ryan Ashbrook]

By default, it's 90 seconds. Then it looks at the max_execution_time PHP configuration and will then use that instead, if it's less than 90 seconds.

Then it looks at wait_timeout in MySQL and if it's less than max_execution_time, it uses that instead.

Then, it looks at the memory_limit PHP configuration and if it's not unlimited, it takes that into account.

Then it will run the task as many times as it can until one of the following happens (in this order):

1. The task indicates it has nothing else to do.
2. If the task is explicitly told to run X amount of times, it will stop when it reaches that amount.
3. If it gets close enough to the timeout that it cannot run another cycle.
4. If it gets close enough to the memory limit that it cannot run another cycle.

[Cach Doan]

Sorry for bringing this up again.

I need to send emails to over 13,000 people who want to get my newsletters and updates. My Amazon SES account lets me send only 14 emails every second. What should I do to send them out efficiently? If I set it to send 10 emails every second, I think I can send all 13,000 emails in about 22 minutes. So far I haven't found a way to do this with invision power board. I hope someday there is an update and there is an option we can do this.

[Marc]

2 hours ago, Cach Doan said:

Sorry for bringing this up again.

I need to send emails to over 13,000 people who want to get my newsletters and updates. My Amazon SES account lets me send only 14 emails every second. What should I do to send them out efficiently? If I set it to send 10 emails every second, I think I can send all 13,000 emails in about 22 minutes. So far I haven't found a way to do this with invision power board. I hope someday there is an update and there is an option we can do this.

The better option here, to be honest, would be to get a mail provider who can deal with your sites volume. We offer integration such as sendgrid for this purpose, which many use to ensure mail deliverability. It may be worth taking a look at that in your case

[Sonya*]

@Marc Stridgen can you please confirm it? The default Amazon SES limitations are:

Do you mean, there is no way to send out IPS bulk mail with Amazon SES? 

[Marc]

2 minutes ago, Sonya* said:

@Marc Stridgen can you please confirm it? The default Amazon SES limitations are:

Do you mean, there is no way to send out IPS bulk mail with Amazon SES? 

You can send out mail via any email method. What you cant do is send out email that is beyond the limitations of your mail provider

[Sonya*]

Just now, Marc Stridgen said:

What you cant do is send out email that is beyond the limitations of your mail provider

Just to clarify. Can I somehow respect the limitations above with default IPS settings? Or not?

[Marc]

1 minute ago, Sonya* said:

Just to clarify. Can I somehow respect the limitations above with default IPS settings? Or not?

There is no such function to say "Only run x per y period" within the software

[opentype]

I used SES for some of my communities over the last couple of years (via SMTP). The ‘send-rate per second’ didn’t seem to matter for this delivery method. It was pushing out the several hundred bulk mails per task without issues. I did get warnings about getting close to the send limit per 24 hours though. 

[Sonya*]

3 minutes ago, Marc Stridgen said:

There is no such function to say "Only run x per y period" within the software

Means? I cannot use IPS bulk mail with Amazon SES right now. Right? 

[Marc]

3 minutes ago, Sonya* said:

Means? I cannot use IPS bulk mail with Amazon SES right now. Right? 

If you are sending more than the limit you have, then no. However there are many people using SES without issues. Im honestly not sure how better I can answer there. We do not have a function that limits email to only send so many within a given period, and you would require an email provider that is suitable for your uses. There are many many email providers that would not be suitable, and many that are

[Sonya*]

1 minute ago, Marc Stridgen said:

If you are sending more than the limit you have, then no.

If IPS sends out more than the limit, Amazon SES has…. My question was how IPS can be set to respect the limits above. As I can see from the answers here, there are no settings and BULK_MAILS_PER_CYCLE does nothing. Theoretically, bulk mails via Amazon SES (SMTP) should not work. But in practice it does. This is all I want to know. Thanks.

 

[Marc]

3 minutes ago, Sonya* said:

If IPS sends out more than the limit, Amazon SES has…. My question was how IPS can be set to respect the limits above.

It cant. Again, there are no ways in which to set x per y period. For further clarify, please see the below. 

On 1/25/2024 at 5:19 PM, Ryan Ashbrook said:

By default, it's 90 seconds. Then it looks at the max_execution_time PHP configuration and will then use that instead, if it's less than 90 seconds.

Then it looks at wait_timeout in MySQL and if it's less than max_execution_time, it uses that instead.

Then, it looks at the memory_limit PHP configuration and if it's not unlimited, it takes that into account.

Then it will run the task as many times as it can until one of the following happens (in this order):

1. The task indicates it has nothing else to do.
2. If the task is explicitly told to run X amount of times, it will stop when it reaches that amount.
3. If it gets close enough to the timeout that it cannot run another cycle.
4. If it gets close enough to the memory limit that it cannot run another cycle.

 

5 minutes ago, Sonya* said:

Theoretically, bulk mails via Amazon SES (SMTP) should not work. But in practice it does. This is all I want to know. Thanks.

If the question is "Why is it working?" then you would need to ask Amazon that question. We can tell you only how we send the mail. We cant tell you why they are accepting mail, or why they dont accept mail. Only your mail provider can tell you that

[Sonya*]

48 minutes ago, Marc Stridgen said:

There are many many email providers that would not be suitable, and many that are

I know it's not your headache, but I can't use many email providers for one of my projects. Due to political restrictions. Even though I have a completely non-political project, I have been rejected by most email providers so far. Amazon is the only one that accepts us at the moment. Again, it's not your problem, but some of us don't always have a choice 😉.

It's enough for me to know that this works somehow. Thank you!

Edited March 20 by Sonya*

[Randy Calvert]

Just to toss it out there… you can work with AWS to request higher sending limits. The default values are not the only ones possible. 🙂 

[Cach Doan]

11 hours ago, opentype said:

I used SES for some of my communities over the last couple of years (via SMTP). The ‘send-rate per second’ didn’t seem to matter for this delivery method. It was pushing out the several hundred bulk mails per task without issues. I did get warnings about getting close to the send limit per 24 hours though. 

What was your rate for emails per second on your Amazon SES account that you can use push through several hundreds email per task?

Also when you said several hundreds, how many hundred? Can I go 500 at a time?

Edited March 21 by Cach Doan

[Randy Calvert]

The default value for SES is 14 a second… if you extrapolate that, it is 840 per minute. But if someone’s sending needs are higher, it’s possible to request a higher limit from AWS. 

[Cach Doan]

Anyway, I just sent a bulk email out to 668 members without any issues.

Here's the proof from invision power

 

Here's my Amazon SES quota.

 

I did it twice:

 

 

Edited March 21 by Cach Doan

[Cach Doan]

I just did another task over 1k emails. (I have 21k members in my community)

I have over 21k members and about 70% of them subscribed to the newsletter.