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 _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel