[squid-dev] [PATCH] Happy Eyeballs: Use each fully resolved destination ASAP

[Alex Rousskov]

On 05/24/2017 10:27 PM, Amos Jeffries wrote:

> Are you aware of the socket expense issue inherent in Happy Eyeballs?

Yes, I am. This series of patches does not deal with the Happy Eyeballs
parts that increase the number of sockets, but, if those parts are
eventually implemented, the increase should be taken into account (e.g.,
limited or enabled/disabled via configuration), of course. Discussing
whether and how to do that is outside this thread scope.


>>> The synchronous processing may make the one transaction
>>> reach connection faster, but that is just taking CPU cycles from /
>>> slowing other transactions.

>> The patch parallelizes second DNS lookup and first HTTP transaction
>> execution. That parallelization is not about CPU cycles but about the
>> time the first HTTP transaction spends waiting for (blocked on) that
>> second (and usually unused) DNS lookup in the old code. The patched code
>> does not wait/block. Again, the gains from this optimization are not the
>> goal, but some environments will see them.

>>> It might be worth initiating that noteDestination() sub-path as async
>>> step to avoid the remaining delay.

>> Yes, and my second thread email stated that much. However, the reason
>> for making that call async is not performance optimization (async calls
>> make performance worse, not better!) or delays. The reason is to shorten
>> the call stack, reducing the number of balls in the air and localizing
>> bugs.

> I would be interested if there are any measurements on the above two
> points

Sorry, I seem to have lost context here: The measurements of which "two
points" would you like to see? And what kind of measurements? I see
nothing in the previous email that makes sense to measure (in this
project scope)...

If you are talking about the "parallelizes second DNS lookup and first
HTTP transaction execution" part, then the performance gain from that
change can be as huge/tiny as the tester wants -- it heavily depends on
DNS and HTTP transaction delays.


Thank you,

Alex.