Administrative and Maintenance Tools - Cron Based E-Mail Sending

This modification is no longer available or supported.

This is a 3.6 specific port of the 3.5 Modification.

In default vBulletin if you send a large number of e-mails, vbulletin either puts them in it's queue and then attempts to send them as each user visits a page, or just simply tries to send them straight away (This is the case when you use the Administrators email users inteface).

As a result of this your server can become seriously overloaded very quickly - so sending several thousand e-mails (like a newsletter) can become very difficult (hours spent clicking 'next' in the ACP) - as a result of these problems, this very simple modification was born.

This modification does two things ;

1. E-mails from the ACP inteface are sent to the mail queue, not straight to the mail system.

2. The processing of the mail queue is set-up as a vb cron item.

Obviously for this to work, you must turn on e-mail queuing in the ACP options - set 'Use Mailqueue System' to 'Yes', and 'Number of Emails to Send Per Batch' to a realistic value (based on the cron setting, as below).

There are two realisitc options for the cron job, you can either set it to run every minute, and set the items to be processed to something small (like 10), or you can do what this modification does by default and set it to run every 10 minutes, and set the items to be processed to something larger (like 100).

Remember, 10 per minute = 600 per hour, 100 per 10 minutes is also 600 per hour. The numbers really depend on how quick you want large queues processed, and how much your mail server can handle in one go.

Once working, when using the ACP mail users inteface, remember you can set it to process 9999 at once (not 500 or whatever) as the mails will now go into the queue, not be sent directly.

Note: This modification will affect any queued e-mails such as subscription e-mails. It will not affect registration e-mails as they bypass queuing anyway.


Upgrading from the 3.5 version.
If you have the 3.5 version installed then you don't need to upgrade - however if you decide to upgrade then you need to delete the current cron job in the Scheduled Tasks Manager and then import the product xml via the ACP Product Manager. The file edits do not need to be changed.


Queue Size

Antivirus has posted a nifty little addon that displays the current size of the mail queue here.



History:

v1.12 : First Release for vB 3.6.

[dartho]

Originally Posted by Paul M

Sorry, but I don't understand what you mean by this.

To re-phrase, are missed cron jobs still executed at the next opporutinty? For example, if there are no visitors for 2 hours then the (default - every 10 minutes) 'process mail queue' cron job would would miss 12 'executions' of the job. Would these missed 'executions' then all (12) be run at the next opportunity, or would the never be run.

The reason I ask is that if I were on a throttled account of say 500 emails/hour and had configured my vb system to send batches of 100 emails every 10 minutes (using this add-on) and if all 12 missed executions were run at the next opportunity, that would be 1200 emails send in a short space of time - totally trashing my 500 email/hour limit.

Clear as mud?

[Paul M]

No, that will not happen - the cron job is only triggered once - if you have no visitors for two hours then it won't fire 12 times, just the once.

[laura66a]

Originally Posted by Paul M

Huh ?

Can you please be a bit more specific.

Sure.

I have Cron Mail Queue installed and it was working great. I have it set to send 5 emails per minute which works fine for my site when I send out my weekly updates.

I recently changed my SMTP port setting from 25 to 587 at the request of my provider. There is a vBulletin option for this, but you also have to change SMTP_Port= in PHP to 587 as well to get it to work.

After I made the change, my last round of weekly updates went out all at once instead of 5 per minute. They all were successful, but they did go out all at once.

Laura

[Paul M]

The change you made cannot affect this modification in any way, maybe your e-mail server just queued them all up.

[laura66a]

Originally Posted by Paul M

The change you made cannot affect this modification in any way, maybe your e-mail server just queued them all up.

Perhaps it can't affect the mod, but the PHP change can certainly affect the way vBulletin works relative to the mod.

I did change this back to port 25 and it worked as expected sending 5 emails per minute.

Laura

[plothook]

* Clicks Mark as Uninstalled *
Just what we needed to get all our stuff out past our hosts 200 emails/hour limit @30 emails /10 minutes
Now everyone will get their daily e-mail notifications, even if it does take the system 3-4 hours to get the job done.

Thanks Paul!
---------------------------------
now if it only were truely CRON based and didn't depend on site activity, though we always get more than enough site hits to trigger things

[SVTCobraLTD]

Installed using hostgator. Thank you, exactually what I needed and will be setting it to 25 emails per batch. Thanks - Nominated for mod of the month.

SVT

[SVTCobraLTD]

Originally Posted by Antivirus

Great modification Paul, really helps with sending out emails to large amounts of members. I found myself wondering how many emails were in the queue quite often however, and I got tired of manually running a SELECT query in the console to find out how many emails were remaining in the queue... so i coded the attached add-on for your mod which adds the quantity of remaining emails in the mail queue to the AdminCP page.

You can see a screenpic of what it does in the attached "screenie.gif" image. I just thought I would share it with everyone who's using this mod, makes life a little easier.

A great addition to this great hack.

SVT

[dartho]

^
|
|
|

What (s)he said x 2 :up:

[Farcaster]

I have to agree. This plus the crontab based vbcron jobs is a killer combination!