On Sun, Nov 05, 2000 at 11:15:50AM -0700, Sean Reifschneider wrote:
> Unless you're running a file-system that doesn't do effectively a
> linear scan of a directory for every insert and remove operation,
> keeping the todo small is a very good idea. Otherwise you chew up
> a lot of time in the kernel. That's why I said it's a good idea
> to have a scheduler that gives precedence to the todo queue. Why
> do you disagree?
I totally agree with the performance gain of the big todo patch on such
systems.
However, if you e.g. have a busy "incoming" server I don't see why it
would be good to give precedence to processing the incoming queue.
IMHO you can't generalize that. It heavily depends on the sort of
messages you receive.
If within one loop of the scheduler you always have one incoming
message with one remote delivery it's a pari situation, but if
you always have one incoming message with more than one remote delivery
it would be IMHO better to priorize deliveries.
> >Sorry? No you can't, at least not with a lot of the bounces. If
> >qmail-remote gets a permantent error, it signals back to qmail-send
> >and a bounce is generated internally (i.e. injected into the queue).
> >You can't avoid this happen locally.
>
> Sorry? Yes you can. If it's important to you to do so, simply move
> into place a qmail-queue which injects the messages into the other queue.
> If you're still injecting into the main queue at this time, you'll need
> to call qmail-queue directly. It all comes down to how important it
> is to you to get better performance.
Ok, thats a valid point :-)
I'll try setting up a second queue (i.e. for bounces) on the "waving"
server and see if performance changes.
> The images posted previously suggest that their biggest problem was with
> remote bounces, however. If they were local bounces, I would expect to
> have seen consistently lower performance, but the way it looked to me
> was that delivery would pick up quite nicely and run for a while until
> remote hosts started turning around a bunch of bounces. That was just
> a guess, but it seemed not entirely an unreasonable one.
In the first image (wavy server) the MX of the sender address is set to
another server. The slow down because of bounces are those bounces that
get a permanent error directly from qmail-remote.
\Maex
--
SpaceNet GmbH | http://www.Space.Net/ | Stress is when you wake
Research & Development | mailto:[EMAIL PROTECTED] | up screaming and you
Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | realize you haven't
D-80807 Muenchen | Fax: +49 (89) 32356-299 | fallen asleep yet.
