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 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?
Patrik
