mailing list script timout problem
Quote:
>Hi all,
>I wrote this script that fetches a list of email addresses from a database
>and sends a newsletter to each with a "for"-loop. (look below for example)
>----------------------------------------------------------------------------
>-------------------
>...
>$sent = 0;
>$row = mysql_fetch_assoc($query);
>for ($i = 0; $i < mysql_num_rows($query); $i ++) {
> $mailTo = $row['email']; // addressee
> $subject = 'MyNewsletter'; // subject
> $msg = $body; // message body
> $sendIt = mail($mailTo, $subject, $msg, $mailFrom): //construct email
> if ($sendIt) {
> $sent++;
> }
>}
>...
>----------------------------------------------------------------------------
>-------------------
>I've noticed that at times the script doesn't make it to the end of the
>list, which contains about 200 entries, I guess this is because of the
>execution time limit set by my host, or php itself.
>If anyone has any ideas on how to work around this, I would very much
>appreciate your help.
>tia,
>somaBoy MX
Just a quick thought.. To prevent killing sendmail with large hunks of
e-mail what if you combined the time out with a sleep after a set
count? Use set_time_out() to keep PHP from bailing out. Then use sleep
to keep from drowning sendmail. Let's say we have 2000 e-mail
messages. To be safe, you could break them into blocks of 100.
So we would have message blocks. After sending 150 we sleep say 10
seconds and send another hundread.
Another (possible) solution.
Ok. Let's say the mailing list in question is super popular and we
have 20,000 users. Obviously, at this point we should be able to
afford a decent mailing list manager, but for the sake of argument we
don't have one. The above aproach, wich is already screaming in agony,
simply drops dead with a list this size.
Step 1.
With blocks of 150 that gives us about 134 blocks (with the last one
having less than 150).
Step 2.
Fake the schedule. With super massive list like this one, the only way
I can see to do it is by scheduling the e-mails several minutes apart
using a cron job. We could eaisly create a script will queary the
database, get a block, send it, record where it stopped and die.
The cron job would execute this script several times, with a delay of
say 5 minutes between script calls. This would take about 11 our 12
hours to send all this junk. Not very practical I must admit.
Lowering the delay by even a small amount, or increasing the batch
size by a small amount will have a drastic effect (batches of 200 sent
3 minutes apart would only take about five hours. )
Step 3.
Find new ISP. Apologize to the developers of both PHP and sendmail and
promise never to do it again.
The above examples make an attempt to be at least a little bit
friendly to the ISP and sendmail. Maybe it would work, maybe not.
Comments?
---
David Hamilton
www.potentialcreations.com