Is Cron Job Only Way To Slow Queue Processing?

Hi,
Novice User here!

With 85 subscribers I have more on my mail list than my host allows per hour before it blocks the sending of emails.

I was hoping to find a setting in phpList that allows me to specify a number of emails to be sent immediately together with a delay before phpList attempts to process the emails for the remaining subscribers on the list. I assumed that with these two bits of data phpList would be able to automatically re-process the queue after the pre-set delay until such time as the entire queue was processed. However, I cannot find such a facility.

Is there any facility within the program to cope with this, presumably very common, requirement - other than a Cron job?

If not, can someone point in in the direction of sample code that will achieve this. I’m completely new to Cron jobs!

May we assume you are using phpList version 3.x.x?

If so, simply copy the following into your config/config.php file (you’ll find the data in your config/config-extended.php file by that way).

The code below assumes a limit of 20 emails in 10 minutes (600 seconds) with a 3 second pause between messages.

# batch processing
# if you are on a shared host, it will probably be appreciated if you don't send
# out loads of emails in one go. To do this, you can configure batch processing.
# Please note, the following two values can be overridden by your ISP by using
# a server wide configuration. So if you notice these values to be different
# in reality, that may be the case

# max messages to process
# if there are multiple messages in the queue, set a maximum to work on
define('MAX_PROCESS_MESSAGE',999);

# define the amount of emails you want to send per period. If 0, batch processing
# is disabled and messages are sent out as fast as possible
define("MAILQUEUE_BATCH_SIZE",20); 

# define the length of one batch processing period, in seconds (3600 is an hour)
define("MAILQUEUE_BATCH_PERIOD",600);

# to avoid overloading the server that sends your email, you can add a little delay
# between messages that will spread the load of sending
# you will need to find a good value for your own server
# value is in seconds, and you can use fractions, eg "0.5" is half a second
# (or you can play with the autothrottle below)
define('MAILQUEUE_THROTTLE',3); 

An explaination as to why there are two config files is given here.

Hi Dragonrider,

Looks like your response should sort it. Many thanks.

Seems like it’s another case of newbie idiocy strikes again. Should have thought of going through the config file. Doh!

I’m running the 3.3.1

So if my host limits me to 50 emails per hour, then to allow me to send up to 10 non-maillist emails in any hour, these settings should do the trick:

‘MAILQUEUE_BATCH_SIZE’, 40
MAILQUEUE_BATCH_PERIOD’, 3600

If I have around 90 subscribers. I guess these settings mean that I would need to keep the browser window open for over two hours. Would processing work if I had the window open but in another “workspace” (i.e. one of an number of “desktops” I can switch between) or is the only practical thing to move to using a CRON job?

Currently, I don’t hit my server sending limits and with the default settings which include “MAILQUEUE_THROTTLE’, 0” my campaign takes around 5 minutes to send. but once I do and if I continue to launch the queue from the web interface will there be any benefit to me or my host in turning on MAILQUEUE_AUTOTHROTTLE?

I’m never likely to hit the MAX_PROCESS_MESSAGE’,999 limit. However, I’m unclear what that does. Does it simply stop any mail list queue greater than 999 from being processed? Why would you want that?

Greg

Hi Greg,
Your settings will send 40 per hour, and if you use the browser method, then you’ll need to keep a window open to run the sending instruction in phpList for the 2nd and third hours.

A CRON job will do this without the need for a browser window as these are server side commands. How that works? Smacks of the Black Arts to me, sorry.

MAX_PROCESS_MESSAGE’,999 just means the maximum number of messages, though I think that really means the number of campaigns that can be run at a time.