On Tue, May 14, 2013 at 10:37:07AM -0400, Wietse Venema wrote:
> > Hmm, I am afraid that such a small window makes nearly no difference as
> > far as the delivery agent bottleneck is concerned.
>
> It should be OK for fast connections.
>
> > > It can be a little smarter than that. It can group SMTP/TCP connection
> > > requests by nexthop, effectively creating a connection request queue.
> > >
> > > If a nexthop is quick, then its connection requests clear the
> > > connection request queue quickly, so this queue could be given
> > > favorable scheduling preference. If a nexthop is slow, then this
> > > really wants a back-channel to the queue manager to provide selective
> > > scheduler or queue-reader feedback of some kind.
> >
> > Isn't that just duplicating the per-destination concurrency window /
> > dead site detection mechanism which is already in place?
>
> Unlike qmgr, prescreen knows that a destination is slow, so it
> can prioritize connection requests.
How does it know this? Remembering which destinations took a long
time to connect (typically timed out) in the past?
What is the concurrency for trying to make such connections? It
should be higher, but there is some risk that the heuristic data
is stale, and connections are made too fast. Which leads to a slow
mail building up in the active queue.
What is the resulting output rate for the slow path? Does prescreen
help this exceed the input rate from the deferred queue?
--
Viktor.
