Databases
StackOverflow2013
Postsdbo
POPHP/curl: namelookup_time/dns slowing requests
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POPHP/curl: namelookup_time/dns slowing requests
    primarykey
    data
    text
    <p>EDIT: Found part of the cause - see bottom.</p> <p>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.</p> <p>This is a problem since our app makes many calls to this subnet to build a page, so the seconds add up.</p> <p>My curl_getinfo response (url snipped out)</p> <pre><code>array 'url' =&gt; string ' &lt; SNIPPED &gt; '... (length=1449) 'content_type' =&gt; string 'text/plain; charset=utf-8' (length=25) 'http_code' =&gt; int 200 'header_size' =&gt; int 227 'request_size' =&gt; int 1480 'filetime' =&gt; int -1 'ssl_verify_result' =&gt; int 0 'redirect_count' =&gt; int 0 'total_time' =&gt; float 1.165444 'namelookup_time' =&gt; float 1.001272 'connect_time' =&gt; float 1.017765 'pretransfer_time' =&gt; float 1.017781 'size_upload' =&gt; float 0 'size_download' =&gt; float 92562 'speed_download' =&gt; float 79422 'speed_upload' =&gt; float 0 'download_content_length' =&gt; float 92562 'upload_content_length' =&gt; float 0 'starttransfer_time' =&gt; float 1.043094 'redirect_time' =&gt; float 0 'certinfo' =&gt; array empty 'redirect_url' =&gt; string '' (length=0) </code></pre> <p>I have a suspicion that the name lookup lag is due to IPv6, so I tried the following:</p> <p>1) Followed the directions here to turn off Ipv6 on OSX, including reboot. I set all instances of IPv6 to <strong>INACTIVE</strong> like the article suggested.</p> <p><a href="http://community.centrify.com/t5/Express-for-Mac-Tips-and-Tricks/Using-local-domains-with-Centrify-Directcontrol-on-the-Mac/ba-p/3724" rel="nofollow">http://community.centrify.com/t5/Express-for-Mac-Tips-and-Tricks/Using-local-domains-with-Centrify-Directcontrol-on-the-Mac/ba-p/3724</a></p> <p>I confirmed that my Mac didn't have IPv6 support here: <a href="http://ipv6test.google.com/" rel="nofollow">http://ipv6test.google.com/</a>.</p> <p>2) Rebuilt PHP with --disable-ipv6.</p> <p>php -i shows: IPv6 Support => disabled</p> <p>although in the curl section, it says "IPv6 => Yes", and I don't know how to surgically turn this off.</p> <p>3) Ran this before the curl call:</p> <p>curl_setopt($c, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );</p> <p>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? :)</p> <p>(Note - I've googled and SO'ed this question, but to no avail..)</p> <p>Edit: answering ckhan's questions below:<br> 1) I get the same 1 sec+ namelookup_time using an IP address or a FQDN: </p> <pre><code>'url' =&gt; string 'HTTP://172.19.105.171:8070 &lt;SNIPPED&gt; '... (length=1439) ... 'namelookup_time' =&gt; float 1.001309 </code></pre> <p>2) The command line client doesn't have the same problem:</p> <pre><code># url.txt has the same url as the above curl call time cat url.txt |xargs curl &lt;... response output ...&gt; real 0m0.053s user 0m0.009s sys 0m0.008s </code></pre> <p>3) dig seems to have no problem with accessing the server.</p> <pre><code>dig 172.19.105.171 ... ;; Query time: 77 msec ... </code></pre> <p>My environment:<br> PHP 5.3.8<br> OSX 10.7.3 </p> <p><strong>Partial solution</strong></p> <p>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).</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USvaughnkoch
    1. USvaughnkoch
    plurals
    1. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POPHP/curl: namelookup_time/dns slowing requests
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POPHP/curl: namelookup_time/dns slowing requests
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POPHP/curl: namelookup_time/dns slowing requests
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO3 questions: 1) Have you verified that using IP address instead of name is fast? 2) Can you get PHP out of the loop, and confirm that just using curl command line client has the same problem? 3) can you get curl out of the loop, and confirm that nslookup/dig are slow?
      singulars
      1. POPHP/curl: namelookup_time/dns slowing requests
      1. USckhan
    2. COI'd run traceroute and compare to the fast linux box - they really are on the same subnet, right?
      singulars
      1. POPHP/curl: namelookup_time/dns slowing requests
      1. USckhan
    3. COGood thinking. I did compare them earlier, the traceroute times were comparable (15-30 ms), not 1 sec+ though.
      singulars
      1. POPHP/curl: namelookup_time/dns slowing requests
      1. USvaughnkoch
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload