Viktor Dukhovni:
> On Wed, May 15, 2013 at 12:54:20PM -0400, Wietse Venema wrote:
> 
> > Viktor Dukhovni:
> > > Postfix already exerts too little back-pressure when the queue
> > > fills,
> > 
> > Agreed.
> > 
> > > ignoring the deferred queue while taking more new mail
> > > quickly will eliminate most of that (when the incoming queue is
> > 
> > You are mis-representing.
> > 
> > There is no intent to IGNORE the deferred queue. After all it is
> > allowed to occupy 80% of all the delivery agents! The intent is
> > to give it only 80% or whatever. As soon as a deferred message
> > clears the queue it is replaced with another one.
> 
> Yes, but the effect is the same, the input queue continues to drain
> quickly with a substantial reduction in the already light back-pressure,
> and the deferred queue grows.

[discussion of what I perceive as a many-knob solution involving
initial concurrency, cohort sizes, and more]

I don't want to disparage your contribution to the discussion, but
I think that software's job is to change one complex problem into
a simpler problem (examples from other domains: driving a car with
automatic transmission; controlling temperature with a thermostat).

I have seen (too) many examples of software that does too little
in this respect, leaving the user with a complex multi-knob solution.
Thus, my reluctance to implement Postfix solutions that rely on
many-knob solutions.

Said otherwise, the typical Postfix operator should not need a math
degree from Princeton. However it may well take a math degree to
figure out how one complex problem can be mapped onto one parameter.

Patrik appears to have a source of mail that will never be delivered.
He does not want to run a huge number of daemons; that is just
wasteful. Knowing that some mail will never clear the queue, he just
doesn't want such mail to bog down other deliveries.

>From that perspective, the natural solution is to reserve some fraction
X of resources to the delivery of mail that is likely to be deliverable
(as a proxy: mail that is new).

        Wietse

Reply via email to