Administrative and Maintenance Tools - Cron based e-mail sending

As of 24 Nov 2017 this modification has been withdrawn.

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

The result of this can be that your server can gets seriously overloaded very quickly - or on many hosts, you get banned for exceeding their e-mail sending limits. This can make sending several thousand e-mails (like a newsletter) very difficult.

This modification does two things ;

1. The processing of the mail queue is set-up as a vbulletin cron item.

2. Allows you to add a small delay before each e-mail is sent (between 1 and 9 seconds).

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

Use option 2 carefully, otherwise you will slow your e-mail system right down.

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 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.

This modification includes the code by Antivirus that displays the current size of the mail queue.


History:

v3.8.001 : First Release for vB 3.8.

[PPUS]

OK, thanks Paul... so I have it set as:

Number of Emails to Send Per Batch: 50 and the delay at 1 second. Is this the only setting I need? I do not want to exceed 500/hour as I am allowed 600 and the extra 100 is for other functions and email users on the server. I am I correct that there are no settings in the mod/hack, only those in the ACP?

Gotta say I am nervous as a long tail cat in a room of rocking chairs.

[Paul M]

The cron runs 6 times an hour (every 10 minutes), so 50 x 6 = 300 an hour, well under your 500/Hr - you are fine.

[PPUS]

Originally Posted by Paul M

The cron runs 6 times an hour (every 10 minutes), so 50 x 6 = 300 an hour, well under your 500/Hr - you are fine.

Ahh, the light bulb comes on, I did not realize the cron ran 6x per hour. So whatever I put in the field is x6 to give me the hourly send rate. So a quick math lesson for other:

Setting the "Number of Emails to Send Per Batch" to:

50 = 300/hr
60 = 360/hr
70 = 420/hr
80 = 480/hr
90 = 540/hr

Perfect! I got it now, Thanks again Paul.

[tehPARADOX]

I just wanted to stop by to warn you guys:

If you have say over 200,000 emails queued and you decide to upgrade vbulletin, make sure to do the file edits on the new files immediately before uploading it!

I made the noob mistake of uploading a fresh functions.php onto the server. Within seconds, all the emails were sent out, bringing my server to a halt with a load of 1000+.

I didn't know what the heck was going on until I saw exim crash.

[obmob]

Hmm... yeah, editing first might be a wise action

[Plasma2002]

Hey Paul,

Ive been using this addon for quite a while now and it has been a lifesaver... but i have a question.

Maybe it has nothing to do with your addon, and its more of a vBulletin thing, but you may know the answer anyways


I dont have much traffic on my forums (most the traffic is on the main site), so this becomes a problem when, say, in the middle of the night, i have a newsletter that needs to go out to 8,000 people that doesnt get finished until the next couple weeks.

What i tried to do to remedy this was make my local machine at home just do a simple wget of vBulletin's cron.php file every 5 minutes.

I figured this would be the best solution... but for some reason, when i look at my mailqueue from the adminpanel, it shows that the number of unsent mails never changed when i just hit the cron.php file... but it works fine if i leave a browser on the forums and make it reaload every 60 seconds.

Would you happen to have any idea how i can manually execute the cron and make my emails send out when my forums are empty?


Thanks


EDIT: I found out my problem, in case anybody got here by googling. it was in fact my wget script... if you are trying to run your cron's manually, simply make something hit cron.php on your forums.

[Paul M]

Sorry, I dont.

[cellow]

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.

All my activation links are queued. My Users are waiting up to 10 minutes for their activation e-mails.

How can i solve this problem?

[Paul M]

As it says, activation e-mails are not queued by vb.

[cellow]

did you test it on your forum? Why my vb queued activation links?
how can i solve this problem?