[Copying queue files introduces major complexity into the design
of Postfix's queue handling code, which is based on writing a queue
file only once].

Ben Rosengart:
> > If I have the choice between using two Postfix instances versus
> > doubling the complexity of Postfix's queue management code, then
> > I will take the two Postfix instance approach any time, because it
> > needs less code and therefore it is more reliable. This may waste
> > a few cycles and bytes.
>
> I was thinking less of the waste of machine resources than the
> waste of administrator time and effort. As things stand now,
> everyone has to figure out this strategy for themselves, or find
> it out from the mailing list. If it were do-able with a configuration
> parameter, it would be much easier to "discover" it.

That can be fixed with documentation, and that documentation is
needed only for the people who need fallback relay setups. Doubling
the complexity of Postfix's queue management code carries a huge
cost for everyone.

> > In fact, I am going back to an earlier idea to have a queue that
> > does not move queue files at all. It uses append and truncate and
> > thereby saves a tremendous amount of disk I/O overhead by avoiding
> > the relatively expensive file create, rename and delete operations.
>
> That should be interesting. Are you still designing this, or have
> you begun implementing it? I will be interested to see what kind
> of performance gains appear.

The fsstone source code directory has some rudimentary benchmark
code. Early measurements suggest that the per message latency is
approximately equal to the average disk access time. This queue
organization is still in the design stage.

Some of its implementation ideas may also be useful for the present
queue implementation - have one daemon process handle all queue
file open()s, so that "open for read" requests (i.e. mail delivery)
can be given higher priority than "open for write" requests (i.e.
mail arrival).

This would make Postfix less susceptible to building up a backlog
when smtp daemons overwhelm the queue manager, and would make
Postfix quicker getting a backlog out the door.

        Wietse
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]