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

On 02/07/2008, 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?

The spooling/queueing architecture is certainly an area which could be
worked on. As Philip would regularly point out, Exim was designed for
an environment where queueing was the exception rather than the rule.
Since that time there have emerged a number of use cases which put
more reliance on the speed (and perhaps other attributes such as
selectivity) of the queue/de-queue process - maybe a one-size-fits-all
strategy is no longer appropriate.. just musing.

A good start would be to gather high-level requirements.

Peter

--
Peter Bowyer
Email: peter@???
Follow me on Twitter: twitter.com/peeebeee