Re: [exim] Should queue processing be rewritten in Exim?

Pàgina inicial
Delete this message
Reply to this message
Autor: Andrzej Adam Filip
Data:  
A: exim-users
Assumpte: Re: [exim] Should queue processing be rewritten in Exim?
Marc Perkel <marc@???> wrote:

> One thing I noticed is if you really want Exim to be super fast put the
> queues in ram disk. Of course if you crash you lose everything in the
> queue. One way to reduce that is to do a single try and if that try
> fails hand the message off to a different server with a queue on hard
> disk. But - consider this.
>
> Suppose I'm willing to accept a few email lost in the event of a crash
> and I want speed. Here's what I'd like to see.
>
> A message comes in, is completely processed and delivered without
> writing to a queue, all in ram. However if the delivery fails on the
> first try then the message actually is saved to hard disk. Yes - there
> is some exposure to loss of some messages on system crash, and you
> accept that as a trade off for speed.
>
> The queue is the bottleneck in the system. There must be ways to speed
> it up.
>
> Thoughts?


Have you considered delaying ACK of the "final dot" of incoming messages?

For *most* messages delivery time is below 3s. Before giving ACK to
"the final dot" MTA does not have to commit anything from file cache to
disk because it have not "taken over" responsibility for message
delivery. Most senders will accept a 1-2s extra delay (IMHO).

P.S.
Sendmail offers similar option of delaying ACK of "the final dot" but
*without* time limits.

http://groups.google.com/group/comp.mail.sendmail/msg/f67300a37b6157e3
From: Andrzej Adam Filip <anfi@???>
Newsgroups: comp.mail.sendmail
Subject: opportunistic double interative delivery [Was: Unorthodox (?)
idea to improve Sendmail+Milter performance]
Date: Wed, 24 Mar 2004 11:07:00 +0000
Message-ID: <c3rpne$2v0$1@???>

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@??? : anfi@???
Just once, I wish we would encounter an alien menace that wasn't
immune to bullets.
-- The Brigadier, "Dr. Who"