This is note for folks who have big lists and lots of ARs. It's technically not a bug in arpReach... but it's an "issue" that I know a couple of folks have run into and there is a workaround.
I encountered a problem when I go to send a broadcast, sometimes it doesn't send at the expected time.
I was able to track it down to a "queuing" problem.arpReach prioritizes tasks in the following order:
#4 Incoming email processing
#5 Remote bounce processing.
It's reasonable to place the ARs ahead of broadcasts... that way you know that your ARs will go out at the expected time.
However, if your list is big enough and your server is not done sending the ARs before the next cron starts... and that happens a few times in a row... your broadcasts will not go out on time.
In most cases this is due to the MTA bottleneck. I've run numerous mail servers and have noticed that sendmail seems to max out at about 10k emails per hour.
Here's an example:
Let's say you have you have 50,000 folks in your database and each of them is on a daily ARs, and all the ARs are set to go out in the afternoon... then your system is going to try to send 50,000 emails... all with a higher priority than the broadcast. And... let's say that you have all your ARs set to go out in the afternoon (this is also when I like to send my broadcasts)... and let's say you are using Sendmail (which unless you've tweaked it out maxes out at 10,000 emails per hour) then your broadcasts are going to get held up for 5 hours or more... essentially until all the ARs are done.
And... if your folks are on two lists on average, then it's going to be 10 hours before the ARs are done.
The workaround for me, when I want to send a broadcast, is to go into"Scheduled tasks > Settings and disable ARs, Incoming Email Processing, and Remote Bounce Processing... just temporarily until the broadcast starts...which typically happens at the next cron (20 min intervals).
Then once the broadcast starts, I re-enable everything.I've done this for the last 60 or so broadcasts and it's been 100% reliable.
It seems like a good solution is to hire someone to tweak the MTA to increase the throughput, but this is not a trivial job and I'm still looking for someone who knows what they are doing.
Hi Tim and everyone, i have a problem with my broadcasting. After inputting all the setting, sender and message and click saves changes, it take me to my website. The first message i schedule didn't give me such problem but subsequent one. I also notice that whenever i add the message, the problem always appear but if i remove the message and save changes, it won't appear and it will save very well.
Pls, what's the problem. This is urgent to me pls as i need to schedule this messages to my list as quickly as possible. Pls i want response.
Wondering if anyone else has noticed something similar. Is it coincidence... or is it likely that arpReach will perform better if you have more memory allocated to php?
Tim, our developers are going to look at adding an option to a broadcast's settings called something like "Prioritize over other sending" as a quick and easy way to work round this via a simple checkbox.
Great feedback Tim.
If your server is WHM/CPanel, a consultant who can optimize things is Mike Allton.
scripts AT asuservice.com