PHP / curl: namelookup_time / dns slowing requests

EDITAR: encontrou parte da causa – veja a parte inferior.

Estou fazendo uma chamada de curvatura padrão da php. No entanto, parece haver uma interrupção durante a resolução de nomes. Na minha checkbox OSX, o namelookup_time é mais de 1 segundo consistentemente para esta e outras consultas para a mesma sub-rede. Uma checkbox de linux na minha sub-rede que faz a mesma consulta tem uma resposta de 0,02 segundos para a outra sub-rede, então é um problema com a minha checkbox.

Isso é um problema, pois nosso aplicativo faz muitas chamadas para essa sub-rede para criar uma página, então os segundos se summ.

Minha resposta curl_getinfo (url snipped out)

array 'url' => string '  '... (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) 

Tenho a suspeita de que o atraso da pesquisa do nome seja devido ao IPv6, então tentei o seguinte:

1) Seguiu as instruções aqui para desligar Ipv6 no OSX, incluindo reiniciar. Eu configurei todas as instâncias do IPv6 como INACTIVAS como o artigo sugerido.

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

Eu confirmei que meu Mac não tinha o suporte para IPv6 aqui: http://ipv6test.google.com/ .

2) PHP reconstruído com –disable-ipv6.

php -i mostra: Suporte IPv6 => desativado

embora na seção curl, ele diz “IPv6 => Sim”, e eu não sei como remover cirurgicamente isso.

3) Funcionou antes da chamada curl:

curl_setopt ($ c, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);

Infelizmente, nenhuma das etapas acima funcionou – ainda estou recebendo 1 segundo + tempos de resolução de nomes. Alguém tem alguma sugestão de solução de problemas, ou melhor ainda, uma bala mágica? 🙂

(Nota – eu gritei e SO’ed esta pergunta, mas sem proveito …)

Editar: respondendo as perguntas de ckhan abaixo:
1) Eu recebo o mesmo 1 seg + namelookup_time usando um endereço IP ou um FQDN:

 'url' => string 'HTTP://172.19.105.171:8070  '... (length=1439) ... 'namelookup_time' => float 1.001309 

2) O cliente da linha de comando não tem o mesmo problema:

 # url.txt has the same url as the above curl call time cat url.txt |xargs curl  real 0m0.053s user 0m0.009s sys 0m0.008s 

3) cavar parece não ter nenhum problema em acessar o servidor.

 dig 172.19.105.171 ... ;; Query time: 77 msec ... 

Meu ambiente:
PHP 5.3.8
OSX 10.7.3

Solução parcial

O código do aplicativo está usando curl_multi_select, que tem um tempo limite padrão de 1 segundo. Alterar esse atraso para 0,00005 segundos faz com que o retorno da chamada seja muito mais rápido. Então é isso que está causando a demora. No entanto, ainda não sei por que isso é diferente no Linux vs OSX ou o sabor particular do php / libcurl que eu construí (5.3.8).

O código do aplicativo PHP está usando curl_multi_select, que tem um tempo limite padrão de 1 segundo. Alterar esse atraso para 0,00005 segundos faz com que o retorno da chamada seja muito mais rápido. Então é isso que está causando a demora. No entanto, ainda não sei por que isso é diferente no Linux vs OSX ou o sabor particular do php / libcurl que eu construí (5.3.8).

Eu vou abrir uma questão SO diferente para tentar resolver o problema curl_multi_select.