EDIT: Found part of the cause - see bottom.
I'm doing a standard curl call from php. However, there seems to be a hangup during name resolution. On my OSX box, the namelookup_time is over 1 second consistently for this and other queries to the same subnet. A linux box on my subnet doing the same query has a 0.02 second response to the other subnet, so it's a problem with my box.
This is a problem since our app makes many calls to this subnet to build a page, so the seconds add up.
My curl_getinfo response (url snipped out)
array
'url' => string ' < SNIPPED > '... (length=1449)
'content_type' => string 'text/plain; charset=utf-8' (length=25)
'http_code' => int 200
'header_size' => int 227
'request_size' => int 1480
'filetime' => int -1
'ssl_verify_result' => int 0
'redirect_count' => int 0
'total_time' => float 1.165444
'namelookup_time' => float 1.001272
'connect_time' => float 1.017765
'pretransfer_time' => float 1.017781
'size_upload' => float 0
'size_download' => float 92562
'speed_download' => float 79422
'speed_upload' => float 0
'download_content_length' => float 92562
'upload_content_length' => float 0
'starttransfer_time' => float 1.043094
'redirect_time' => float 0
'certinfo' =>
array
empty
'redirect_url' => string '' (length=0)
I have a suspicion that the name lookup lag is due to IPv6, so I tried the following:
1) Followed the directions here to turn off Ipv6 on OSX, including reboot. I set all instances of IPv6 to INACTIVE like the article suggested.
I confirmed that my Mac didn't have IPv6 support here: http://ipv6test.google.com/.
2) Rebuilt PHP with --disable-ipv6.
php -i shows: IPv6 Support => disabled
although in the curl section, it says "IPv6 => Yes", and I don't know how to surgically turn this off.
3) Ran this before the curl call:
curl_setopt($c, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );
Unfortunately, none of the above steps worked - I'm still getting 1 sec+ name resolution times. Does anyone have any troubleshooting suggestions, or better yet, a magic bullet? :)
(Note - I've googled and SO'ed this question, but to no avail..)
Edit: answering ckhan's questions below:
1) I get the same 1 sec+ namelookup_time using an IP address or a FQDN:
'url' => string 'HTTP://172.19.105.171:8070 <SNIPPED> '... (length=1439)
...
'namelookup_time' => float 1.001309
2) The command line client doesn't have the same problem:
# url.txt has the same url as the above curl call
time cat url.txt |xargs curl
<... response output ...>
real 0m0.053s
user 0m0.009s
sys 0m0.008s
3) dig seems to have no problem with accessing the server.
dig 172.19.105.171
...
;; Query time: 77 msec
...
My environment:
PHP 5.3.8
OSX 10.7.3
Partial solution
The app code is using curl_multi_select, which has a default timeout of 1 second. Changing this delay to 0.00005 seconds makes the call return much faster. So that's what's causing the delay. However, I don't yet know why this is different on Linux vs OSX or the particular flavor of php/libcurl that I have built (5.3.8).
The PHP app code is using curl_multi_select, which has a default timeout of 1 second. Changing this delay to 0.00005 seconds makes the call return much faster. So that's what's causing the delay. However, I don't yet know why this is different on Linux vs OSX or the particular flavor of php/libcurl that I have built (5.3.8).
I'm going to open a different SO question to try to resolve the curl_multi_select issue.