fastestmirror plugin very unstable behind transparent cache servers

[Garri Djavadyan]

Hello,

I noticed that current method (socket connection time) used to measure
connect time to HTTP service very unstable in network where
carrier-grade cache servers implemented. In these situations
fastestmirror plugin establishes TCP socket with cache server located in
network operator network, not with a real remote web server. So, socket
connection time is almost identical, even if local mirror web server
exists in the operator's network.

Following are examples from operator's network behind carrier-grade
cache server:

Connection time to server in North America:
$ time echo | nc -q 0 208.74.123.74 80
real	0m0.032s
user	0m0.000s
sys	0m0.001s


Connection time to server located in operator's network:
$ time echo | nc -q 0 91.196.76.102 80

real	0m0.034s
user	0m0.000s
sys	0m0.002s


As you can see, TCP connection to local server looks slower (32ms vs
34ms) than to server across Atlantic ocean. :( 


The layer-7 pings produce more accurate results (693ms vs 67ms). For
example:

$ time curl --head http://208.74.123.74/ping
HTTP/1.0 404 Not Found
Date: Thu, 02 Apr 2015 16:59:56 GMT
Server: Apache/2.2.3 (CentOS)
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive


real	0m0.693s
user	0m0.002s
sys	0m0.001s

-------------

time curl --head http://91.196.76.102/ping
HTTP/1.1 404 Not Found
Server: nginx
Date: Thu, 02 Apr 2015 17:00:46 GMT
Content-Type: text/html
Content-Length: 3652
Connection: keep-alive


real	0m0.067s
user	0m0.002s
sys	0m0.002s


I think fastestmirror plugin should be more smarter, as more and more
operators looks for enterprise level transparent caching solutions.

Thank you for your attention,

Garri