Patrik Rak:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 14.5.2013 14:47, Wietse Venema wrote:
>
> > Yes, I had some time to ponder over this in during the night.
> > Parallelization is easy enough for DNS which does not expire
> > immediately, but the number of TCP connections in progress must be
> > proportional to (but not necessarily equal to) the number of idle
> > delivery agents.
> >
> > Suppose that we set aside a pool of 10 of the 100 delivery agents.
> > Then prescreen can safely have 10 connection requests in progress
> > (connection request here = DNS lookup, TCP handshake and receiving
> > the initial server response).
>
> 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.
Wietse
Wietse
