
Use Curl to identify bottlenecks in your service layers - donohoe
https://gist.github.com/adamkaplan/adf15f0d622f4932f4af
======
ck2
Note that if you use RHEL7/CentOS7, that CURL itself might be the bottleneck
(or versions of curl around 7.29)

They basically decided to make the polling in CURL a blocking delay, simply
waiting 150ms between attempts for things like fetching DNS, if it misses the
first window, it waits another 150ms, etc.

So a 1ms DNS request from the local dns resolver might take 300ms+

[https://ckon.wordpress.com/curl-broken-
centos7-rhel7](https://ckon.wordpress.com/curl-broken-centos7-rhel7)

The most easy way you can solve this is by using the binary-compatible RPMs of
CURL from fedora 19 which were further patched by Redhat.

Otherwise you officially have to wait for RHEL 7.2 / CentOS 7.2 at the end of
this year:

[https://access.redhat.com/documentation/en-
US/Red_Hat_Enterp...](https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/7-Beta/html/7.2_Release_Notes/compiler_and_tools.html#idm4030944)

[https://bugzilla.redhat.com/show_bug.cgi?id=1130239](https://bugzilla.redhat.com/show_bug.cgi?id=1130239)

    
    
         Improved wait times in libcurl
         Libcurl used an unnecessarily long blocking delay for actions with no active file descriptors, 
         even for short operations. This meant that some actions 
         (such as resolving a hostname using /etc/hosts) took an artificially long time to complete. 
         The blocking code in libcurl has now been modified so that the initial delay is short, 
         and gradually increases until an event returns. Fast libcurl operations now complete more quickly.

