Steven Rice <[EMAIL PROTECTED]> wrote:
>If you went out and bought a machine, if it's a p something you will run
>into the limits of qmail-queue way before you will even come close to
>the limits of the hardware. Setting concurrencyremote and
>concurrencylocal will not help. Even if you have it set to 1000, you
>are limited by qmail-queue and the speed of the other guy's server.
>Qmail-queue simply sucks.
No it doesn't.
>Here's why:
>
> If you need to send 20,000 to server/domain A, 15,000 to
> server/domain B, 10,000 to server/domain C and you have
> listA, ListB, listC, (one for each domain), and you send
> a message to listA, ListB, ListC, one after another, or
> even at the same time, ezmlm will process listA, first,
> and send the whole list to qmail-queue. Qmail-queue WILL
> NOT process anything until a message is known to either
> seceed or fail. The concurrencyremote ratio can fall to
> 10/1000 and stay there until the list is finsh.
Here's why you're wrong:
qmail-queue just drops messages in the queue and tells
qmail-send about them. What you say is kind of true if you
replace "qmail-queue" with "qmail-send", but the bit about not
processing anything until a message suceeds or fails is, um,
nonsense.
The problem you seem to have with qmail-send is that it processes
deliveries in the order in which they're received. This property is
known as "fairness", and it's perfectly reasonable in a queuing system
that doesn't support multiple priorities.
It's possible to implement a multiple-priority queue with qmail using
additional qmail installations on the same system (e.g., /var/qmail,
/var/qmail2, etc.) and injecting messages to the appropriate
installation depending upon their priority.
Your monster list server, for example, could have a separate qmail
installation for each of the megalists, as well as one for routine
mail.
> If there where 12 lists like this, it could easily take
> 4 hours to send 120,000 messages, when your machine and
> connection allow qmail-send to handle 120,000 message in
> thirty minutes.
How do you figure that? qmail will keep concurrencyremote
qmail-remotes busy (assuming the resources are available), regardless
of how big the lists are or how many of them there are.
>There's a few thing that needs to be done to improve it:
>
> - qmail-[send] should not handle mail first come, first serve
> This may have worked two or three years ago, but today with
> with dual pII 600 machines for 3 grand, it just doesn't cut it.
Please explain.
> - qmail-queue should not hold up qmail-send
> It should be smart enough that if you have 2000 messages to
> one slow server (sendmail or exchange) it shouldn't hold up
> the whole qmail-send becuase it's trying to send first come
> first serve.
qmail-queue *doesn't* hold up qmail-send. What makes you think it
does?
> - qmail-queue should handle on per server basis and figure out through
> some type of database the aveage speed of servers/domain
> and adjust the queue for servers, so it will send as fast as
>possiable
I disagree. Such "intelligence" is tremendously complicating. I prefer
my qmail simple.
-Dave
