Comments on: Perl whipupitude to the rescue

By: tgape

tgape — Sat, 15 Aug 2009 02:10:47 +0000

Email queuing is somewhat esoteric. Sendmail's recommended configurations, specifically, are only usable for low-volume systems. Even on my home system, I find I get better performance by using significantly different configs. Specifically, Sendmail's 'background' delivery mode is just plain wrong. I don't know if they still recommend this, but they shouldn't - I've shown them plenty of evidence (reports of benchmarks) which indicate it doesn't offer better performance than 'interactive' in best-case scenarios, it's not much better than 'queueonly' or 'deferred' if they're actually configured to be competitive, and under high volume, it breaks. Badly. Also note, if the email was not customized per recipient, you get *much* better performance by including multiple recipients on each body - 95+% of the work is typically on processing the message body, so if you put 10 recipients per body, so that you only have 5k message bodies, you've cut off over 80% of the work. Your MTA can split the message out to the multiple destinations just fine. Even if none of the recipients on a particular message body are on the same destination server, getting it to your own server as one body will save significantly. It only needs to be spam processed once, it only needs to be virus-scanned once, and it only needs to be queued once. Most MTAs can handle 100 recipients per message or more. If downstream MTAs cannot handle it, but they are standards compliant, your MTA will split the message just fine. As such, if your MTA can handle 100 recipients per message, you can easily save over 98% of the message processing... (Disclaimer: really old Notes systems have a bug. Anyone still running Notes 5.x could have issues, under certain uncommon configurations. As I understand it, Notes 6.x, 7.x, and 8.x do not have that issue. Also note, that configuration was *always* misguided/wrong, and anyone *still* running under it should've already found the need to reduce their MaxRecipients setting to something very low, which mitigates it entirely.) Sorry for the long response - former postmaster.

By: Adam Kennedy

Adam Kennedy — Wed, 12 Aug 2009 06:13:53 +0000

If you'd used CPANDB you wouldn't even need to provide the author file as an argument.

By: Lars Balker Rasmussen

Lars Balker Rasmussen — Mon, 03 Aug 2009 16:25:52 +0000

I just got the email. For time-sensitive stuff, this is probably not the best way to send out that amount of email :-)

Received: from pause.fiz-chemie.de (HELO pause.perl.org) (195.149.117.110) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Mon, 03 Aug 2009 08:25:03 -0700 Received: from pause.perl.org (localhost.localdomain [127.0.0.1]) by pause.perl.org (8.13.8/8.13.8/Debian-3) with ESMTP id n6TL86Kq000381 for ; Wed, 29 Jul 2009 23:08:06 +0200

By: Jim Keenan

Jim Keenan — Sun, 02 Aug 2009 17:51:36 +0000

To the best of my knowledge, I have yet to receive the email from PAUSE. I did, however, take the precaution of changing my PAUSE password.

By: david

david — Fri, 31 Jul 2009 01:23:14 +0000

I only know that Andreas ran it. I also know that PAUSE went down at some point. Hopefully coincidental and not that the sysadmins though that thousands of emails sent in a burst was a problem. :-)

By: Jan Dubois

Jan Dubois — Thu, 30 Jul 2009 21:54:36 +0000

Are you sure the script has run to completion yet? I have not received any such notification. I get RT notifications to my @cpan.org address without problem, so I know the email is settup correctly.

By: Ken Williams

Ken Williams — Thu, 30 Jul 2009 21:42:24 +0000

Somehow I didn't get the email, though my CPAN/PAUSE addresses are current. The mailer isn't still running, is it?

By: Purdy

Purdy — Thu, 30 Jul 2009 14:39:00 +0000

Yeah, but can you do it as a one-liner? ;)

Thanks for the heads-up!