> >to this fallback host. That way the mail that's going to go through
> >quickly just goes fsssssssst right through your main server, while
> >the stuff that's going to be slow (because the other end is either
> >slow to connect or down) goes off to this other machine and doesn't
> >clog up the main machine. It turns out to be just an amazing win. And
>
> Any thoughts about how to do this with qmail? Or reasons why it's a
> bad idea?
seems like more trouble than it's worth. if you run sendmail then perhaps
"clogging up the main server" becomes more of an issue. but on my linux box
each qmail-remote process is only taking up about 400k of resident memory,
of which 300k is shared. i'd run out of network pipe long before i started
to slow down the main machine.
there might be some differences at the extremes, for instance if you tried
to run 1000 qmail-remotes simultaneously you'd probably torch the scheduler.
but that's more of a unix problem than a qmail problem.
my solution would be to put multiple machines behind a layer 4 load
balancing switch and inject mail via that mechanism, or if that switch is
too much, change up your injection mechanism to load balance. allman
suggests that this is a general purpose way to offload "slow" mail, but it
looks more useful to me in massive injection situations where a whole bunch
of mail gets queued at once. at steady state i don't think it will make a
difference.
shag
