Home/ Questions/Q 7999829
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T15:36:52+00:00

EDIT: Found part of the cause – see bottom. I’m doing a standard curl

  • 0

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.

http://community.centrify.com/t5/Express-for-Mac-Tips-and-Tricks/Using-local-domains-with-Centrify-Directcontrol-on-the-Mac/ba-p/3724

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).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0