[thelist] scripts performing email merge

[Matt Warden]

Kristy,

Others might be able to give you an more exact figure, but...

On Thu, 10 Feb 2005 14:32:13 -0500, Kristy Frey
<kristenannfrey at yahoo.com> wrote:
> Suppose I have a php script that reads records from a database.  For each
> row it gets email_address and first_name.  Then the script does something
> like this with each row:
> 
> $message_body = "Dear $first_name, \n".$message_body;
> mail($email_address, "Some Newsletter", $message_body);
> 
> Without knowing web server specs or database specs, what do you think would
> be a reasonable rate at which a script like this should send emails?  10 per
> minute, 100 per minute, 1000 per minute, ...?

Probably the biggest thing is how you write the script. If you can
query the user table once and then use the resultset for the remainder
of the script, then your script will run a lot faster than if you are
querying once per iteration.

Assuming you write the script the "right way", I would think that
1000/minute is not unreasonable. However, that depends on whether
you're using mail()/sendmail or some other method.

Some things you might want to think about:
What happens if your script gets interrupted? Is your script able to
pick up where it left off or are people going to get duplicates?
Will there be further per-email processing in the future? If so,
whatever operations you're adding is going to be multiplied 65,000
times.

I always find it difficult to make an argument against a queue system.
If you have Process A which creates the emails and queues them up into
a database table (or the like) and then Process B that checks the
queue every n minutes and sends (based on some rule), then that might
solve both of the above problems. For the latter issue, you could
generate the emails days in advance, even if you aren't going to send
them until friday at 3pm. (However, if you just have a custom Dear
$name, then it's probably not worth it)

The downside is that it requires an update or delete query to the
database to update the queue at least every n sent emails and at worse
at every email sent.

> tell us a wide range of rates (emails / time frame) for this.  Our current
> vendor's script outputs at 5000/hour - making their newsletter script take
> 13 hours during "off hours".  This vendor is well known and should have a
> decent hardware infrastucture. 

They might be trying to keep their servers from being tagged as
spamming. This might be a concern for you as well. Or, they might just
be trying to throttle their bandwidth, I guess.

> hard time googling this - what I have found are products that claim up to
> 500,000 per hour - but I'm interested in a more educated estimate.

That isn't necessarily a lie, especially if it's a hosted solution
with multiple servers.


-- 
Matt Warden
Miami University
Oxford, OH, USA
http://mattwarden.com


This email proudly and graciously contributes to entropy.