view release on metacpan or  search on metacpan

Bulkmail.pm  view on Meta::CPAN

But, basically, Really fast.  Really stupendously incredibly fast.

The last official big benchmark I ran was with v1.11. That list runs through to completion in about
an hour and 43 minutes, which meant that Mail::Bulkmail 1.11 could process (at least) 884 messages per minute or about
53,100 per hour.

The last message sent out was 4,979 bytes.  4979 x 91,140 people is 453,786,060 bytes of data
transferred, or about 453.786 megabytes in 1 hour and 43 minutes.  This is a sustained transfer rate of about 4.4 megabytes
per minute, or 264.34 megabytes per hour.

So then, that tells you how fast the software was back in 1999, 2 major revisions ago. But, invariably, you want to know what it's
like *now*, right? Well, I'll do my best to guesstimate it. However, these tests were not run through an SMTP relay, they were run
using DummyServer in v3.0 and a hacked 2.05 and (severely) hacked 1.11 to insert similar functionality. All data was sent to /dev/null.

Tests were performed on a 5,000 recipient list.

First of all, with envelope sending turned off (average times):

 v1.11......20 seconds	(1.00)
 v3.00......23 seconds	(1.15)
 v2.05......50 seconds	(2.5)

1.11 was the speed champ in this case, but that's not surprising considering the fact that it did a lot less processing than the
other 2. The fact that 3.00 almost catches it should speak to the improvement in the code in the 3.x release. 2.05 was...clunky.

Now then, there's another thing to consider, envelope sending. With envelope sending turned on (average times):

 v3.00......12 seconds	(1.00)
 v2.05......19 seconds	(1.58)
 v1.11......22 seconds	(1.83)

This is with an envelope_limit of 100. So the supposed speed gains that envelope sending were supposed to see in 2.05 never
really materialized. While doing these tests, I discovered a bug in 2.05's use_envelope routine that would sometimes cause it
to slow down substantially. 3.00, with a new routine, was never affected. Incidentally, Bulkmail 2.05 will be faster with trivially
low envelope_limits. Bulkmail 3.00 becomes faster with an envelope_limit greater than 2.

There is also mail merging (filemapping in 1.x) that should be considered. This was benchmarked with Mail::Bulkmail::Dynamic for 3.00.
A simple mail merge with one item was used, and one global item, read from a file, and split on a delimiter (since this was the
only functionality that v1.x had). With mail merge turned on (average times):

 v1.11......20 seconds	(1.00)
 v3.00......35 seconds	(1.75)
 v2.05......40 seconds	(2.00)

And finally, 2.x and 3.x have both had the capability to generate a dynamic message. This is a minimal test with one dynamic
message element, one dynamic header, and a mail merge into the dynamic element:

 v3.00......36 seconds	(1.00)
 v2.05......44 seconds	(1.22)

So 3.x is usually faster than 2.x, but sometimes slower than 1.x. Which makes sense, again due to the added features in 2.x and 3.x.

These tests do not take into account the multi-server capability introduced in 3.00.

Also note that these speeds are only measuring the time it takes to get from Mail::Bulkmail to your SMTP relay. There are no
measurements reflecting how long it may take your SMTP relay to send the data on to the recipients on your list.

=item Am I going to see speeds that fast?

Maybe, maybe not.  It depends on how busy your SMTP server is.  If you have a relatively unused SMTP server with a fair amount
of horsepower and a fast connection, you can easily get these speeds or beyond.  If you have a relatively busy and/or low powered
SMTP server or slow connections, you're not going to reach speeds that fast.

=item How much faster will Mail::Bulkmail be than my current system?

This is a very tough question to answer, since it depends highly upon what your current system is.  For the sake of argument,
let's assume that for your current system, you open an SMTP connection to your server, send a message, and close the connection.
And then repeat.  Open, send, close, etc.

Mail::Bulkmail will I<always> be faster than this approach since it opens one SMTP connection and sends every single message across
on that one connection.  How much faster depends on how busy your server is as well as the size of your list. The connection will
only be closed if you have an error or if you reach the max number of messages to send in a given server connection.

Lets assume (for simplicity's sake) that you have a list of 100,000 people.  We'll also assume that you have a pretty busy
SMTP server and it takes (on average) 25 seconds for the server to respond to a connection request.  We're making 100,000
connection requests (with your old system).  That means 100,000 x 25 seconds = almost 29 days waiting just to make connections
to the server!  Mail::Bulkmail makes one connection, takes 25 seconds for it, and ends up being 100,000x faster!

But, now lets assume that you have a very unbusy SMTP server and it responds to connection requests in .003 seconds.  We're making
100,000 connection requests.  That means 100,000 x .0003 seconds = about 5 minutes waiting to make connections to the server.
Mail::Bulkmail makes on connection, takes .0003 seconds for it, and ends up only being 1666x faster.  But, even though being
1,666 times faster sounds impressive, the world won't stop spinning on its axis if you use your old system and take up an extra
5 minutes.

And this doesn't even begin to take into account systems that don't open and close SMTP connections for each message.

This also doesn't take into account the load balancing between multiple SMTP relays that 3.00 can perform.

In short, there's no way for me to tell how much faster (if at all) it'll be. Try it and find out.

=item Have you benchmarked it against anything else?

Not scientifically.  I've heard that Mail::Bulkmail 1.10 is about 4-5x faster than Listcaster from Mustang Software, but I don't
have any hard numbers.  But nothing beyond that.

If you want to benchmark it against some other system and let me know the results, it'll be much appreciated.  :-)

=item Can I send spam with this thing?

No.  Don't be a jerk.

=item SMTP relay? Wazzat?

All Mail::Bulkmail does is provide you a quick way to relay information from your local machine through to your SMTP relay (which may
be the same machine). Your SMTP relay then sends the messages on to the rest of the world.

So your SMTP server must be configured properly to allow you to relay your messages out. It is recommended that this machine be kept
behind a firewall for security reasons. Make sure that it's configured properly so it's not an open relay. Ask your SysAdmin for help.

=item What about multi-part messages?

Not yet supported. I'll definitely add internal support for multi-part/alternative in the future.

Until then? You can always do the MIME encoding yourself, set your own headers, etc. It's perfectly fine to do it yourself, but you
will have to do it yourself for now.

=item Mail::Bulkmail is really cool, but what'd be even cooler is a front end for the thing! Do you have one of those?

I don't. But check out Mojo Mail:

 http://mojo.skazat.com/

Active community, developer, etc. Looks like a good product.

=item You know, you re-invent a lot of wheels.

Yeah, I do. Hey, c'mon, I write this stuff for the fun of it. And that means that I'm going to do it the way that I want to. :)
Besides, I've never had any problem with re-inventing wheels. After all, if the wheel hadn't been re-invented a few times, we'd
still be using solid plain wooden wheels. Not to say that I necessarily think that I've invented better things here than are
available elsewhere, but I might eventually. Who knows.

Anyway, you're more than free to subclass and over-ride things with "standard" modules if you'd like. ou can make your
own server implementation using Net::SMTP, or your own dynamic message system using Text::Template, or whatever else. Feel free
to use the standards if you'd prefer.

Me? I enjoy re-inventing wheels, so I'll continue to do so.

=item Dude! Warnings is on!