Brandon Yu <[EMAIL PROTECTED]> wrote:
>The messages themselves have been pre-generated and exist as a file and is
>qmail-injected to place them in the queue. The message is the same across
>the board with the exception of some personalization, such as the name.
Ouch. That's gonna cost you dearly.
>Since there are so many messages, we use a perl script to place them in the
>queue at a certain rate, i.e. 50 msgs/second, or whatever rate we choose. By
>injecting them at this rate, we can see whether qmail can keep up with our
>intended rate. With this in mind, does this lessen the burden of disk I/O?
You're going to run into the qmail-send bottleneck: qmail-send won't
dispatch messages to qmail-local or qmail-remote while there are
messages in queue/todo. So not much will go out until all 2M messages
are injected. Therefore, throttling the injections is
counterproductive.
>I have heard of DNSCACHE, currently BIND is running directly on those
>machines. Would it be worthwhile changing out? Can I expect to relive a
>bottleneck in this process?
The only bottleneck you need to relieve is the current bottleneck.
If/when you get to the point that DNS lookups are the bottleneck, then
dnscache would be the thing to try.
Your first bottleneck is going to be qmail-send handling new
injections. After that, it'll be disk I/O or concurrencyremote, most
likely.
>Why would you avoid sorting by domain? I would think it would be more
>efficient handshaking.
qmail-send is going to pass each delivery to a separate qmail-remote.
Sorting will only cause qmail to pound on each domain sequentially. If
your first 2000 subscribers are on AOL and your concurrencyremote is
400, you're going to initiate 400 simultaneous connections to AOL
right off the bat.
>No, I am not using EZMLM. How could I benefit from using it?
If you need customized messages, you can't. If you could use it, you'd
benefit by automatic bounce handling and much more efficient
delivery--one message with 2M recipients vs. 2M messages with 1
recipient.
-Dave
