4 ms·
Use Curl to identify bottlenecks in your service layers
- ck2 11y agoNote 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_Enterprise_Linux/7-Beta/html/7.2_Release_Notes/compiler_and_tools.html#idm4030944 https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... 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.