2012-06-21 15 views
6

Considere este código en un archivo PHP en mi servidor VPS:rizar lenta connect_time

<?php $url = 'http://www.google.com'; 
$ch = curl_init(); 
curl_setopt($ch, CURLOPT_URL, $url); 
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)  Gecko/20041001 Firefox/0.10.1"); 
curl_setopt($ch, CURLOPT_HEADER, 0); 
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); 
$content = curl_exec($ch); 
$ci = curl_getinfo($ch); 
curl_close($ch); 
var_dump($ci); ?> 

devuelve este

array(22) { 
["url"]=> string(21) "http://www.google.com" 
["content_type"]=> string(24) "text/html; charset=UTF-8" 
["http_code"]=> int(200) 
["header_size"]=> int(2055) 
["request_size"]=> int(147) 
["filetime"]=> int(-1) 
["ssl_verify_result"]=> int(0) 
["redirect_count"]=> int(0) 
["total_time"]=> float(50.095466) 
["namelookup_time"]=> float(0.001114) 
["connect_time"]=> float(50.019724) 
["pretransfer_time"]=> float(50.019825) 
["size_upload"]=> float(0) 
["size_download"]=> float(23156) 
["speed_download"]=> float(462) 
["speed_upload"]=> float(0) 
["download_content_length"]=> float(-1) 
["upload_content_length"]=> float(0) 
["starttransfer_time"]=> float(50.070702) 
["redirect_time"]=> float(0) 
["certinfo"]=> array(0) { } 
["redirect_url"]=> string(0) 
"" } 

Después de probar en varios momentos del día, el "connect_time" es consistente en el Marca de 50 segundos. Creo que debería ser 10 veces más rápido si no en la marca de 1 segundo y más abajo.

No conozco la configuración del servidor pero me dijeron que la CPU o la RAM de mi servidor podrían tener la culpa. He utilizado la línea de comando superior para mostrar lo siguiente, que parece bien a mí:

Tareas: 80 en total, 1 funcionamiento, el 79 de dormir, 0 se detuvo, 0 zombi

CPU (s): 0.0 nos% , 0,0% SY, 0,0% de Ni, 100,0% ID, 0,0% WA, 0,0% hi, 0,0% de Si, 0,0% st

Mem: 2097152k total 1273128k utilizado, 824024k libre, 0k tampones

Intercambio: 0k total, 0k usado, 0k libre, 0k en caché

Me pregunto ¿cuál podría ser la causa de este problema?

EDIT: INFORMACIÓN ADICIONAL

resultado de ping www.google.com. Parecía que podía seguir adelante así que detuve el comando después de la 195ª línea

PING www.l.google.com (74.125.224.178) 56 (84) bytes de datos.

64 bytes de lax02s01-in-f18.1e100.net (74.125.224.178): icmp_seq = 1 TTL = 56 tiempo = 12,0 ms

64 bytes de lax02s01-in-f18.1e100.net (74.125.224.178): icmp_seq = 2 TTL = 56 tiempo = 12.1 ms

64 bytes desde lax02s01-in-f18.1e100.net (74.125.224.178): icmp_seq = 3 TTL = 56 tiempo = 11,9 ms

...

64 bytes de lax02s01- in-f18.1e100.net (74.125.224.178): icmp_seq = 194 TTL = 56 tiempo = 11,9 ms

64 bytes desde lax02s01-in-f18.1e100.net (74.125.224.178): icmp_seq = 195 TTL = 56 tiempo = 11,9 ms

--- www.l.google.com estadísticas de ping --- 195 paquetes transmitidos, 194 recibidas, 0% de pérdida de paquetes, el tiempo 194711ms

traceroute wwww.google .com resultado

traceroute to www.google.com (74.125.224.180), 30 saltos max, 60 byte paquetes

1 IP- - - * -. .ip.secureserver.net ( * ) 0,585 ms 0,642 ms 0,778 ms

..

2 be10.trmd0215-01.ars.mgmt.phx3.gdg (208.109.112.126) 0,599 ms 0.777 ms 0,893 ms

3 ip-97-74-253-122.ip.secureserver.net (97.74. 253.122) 11.840 ms 12.119 ms 12.275 ms

4 ip-97-74-253-122.ip.secureserver.net (97.74.253.122) 12.389 ms 12.482 ms 12.600 ms

5 PR01.LAX03.google.com (206.223.123.21) 11.739 ms 11.709 ms 11.707 ms

6 209.85.248.185 (209.85.248.185) 11.986 ms 11.797 ms 11.781 ms

7 72.14.236.11 (72.14.236.11) 12.606 ms 12.363 ms 12.328 ms

8 lax02s01- in-f20.1e100.net (74.125.224.180) 11.774 ms 11.864 ms 11.842 MS

+1

¿Qué tipo de conexión de red tiene, cómo son los recursos en el host VPS? Ejecutar los trabajos anteriores dentro de 1-3 segundos para mí en varias plataformas. Es algo local para su configuración. ¿Puedes hacer ping/traceroute a google y actualizar tu pregunta? Esto probablemente debería estar en serverfault. –

+0

gracias sixeightzero, agregué esa información a mi pregunta – JSL

+0

cambié mi configuración de resolver (resolv.config) a la IP del servidor de nombres de Google. No ayudó – JSL

Respuesta

18

Probar:

curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4); 

Lo anterior impedirá rizo de haber usado primero IPv6.

+2

Como se menciona en los comentarios de OP, este es el truco. Parece que google.com tiene habilitado IPV6 pero el tráfico se enruta incorrectamente. Parece que cURL agotó el tiempo de espera (lo que explicaría el tiempo de conexión constante de 50 segundos) y eventualmente recurrirá a IPV4 para conectarse. Gracias a todos los que ayudaron – JSL

+2

Te amo StackOverflow. Esto me ayudó con algo más que Google.com, pero definitivamente estaba jugando con mis llamadas API. Me di cuenta de que mi servidor remoto realizaba IPv4 de manera predeterminada, razón por la cual era significativamente más rápido que mi servidor local. –

+1

Acabamos de cambiar de servidor y el nuevo servidor estaba dando errores de tiempo de espera. Logré encontrar el origen del problema como el tiempo de conexión curl. Intentaba resolver el problema del tiempo de conexión lento durante un día completo. Me acabas de salvar de pasar más horas en este horrible problema. Gracias. –

0

acabo corrió la misma configuración que le dio y se puso lo siguiente:

array 
    'url' => string 'http://www.google.com' (length=21) 
    'content_type' => string 'text/html; charset=UTF-8' (length=24) 
    'http_code' => int 200 
    'header_size' => int 2079 
    'request_size' => int 151 
    'filetime' => int -1 
    'ssl_verify_result' => int 0 
    'redirect_count' => int 0 
    'total_time' => float 0.281 
    'namelookup_time' => float 0 
    'connect_time' => float 0 
    'pretransfer_time' => float 0 
    'size_upload' => float 0 
    'size_download' => float 23168 
    'speed_download' => float 82448 
    'speed_upload' => float 0 
    'download_content_length' => float -1 
    'upload_content_length' => float 0 
    'starttransfer_time' => float 0.187 
    'redirect_time' => float 0 
    'certinfo' => 
    array 
    empty 
    'redirect_url' => string '' (length=0) 

Mi conjetura es que su conexión con el servidor en sí podría estar teniendo problemas de ancho de banda y/o se grava de alguna manera por otro proceso.

+2

Muchas gracias. Sí, este es el tipo de valores de tiempo que creo que son normales para este trabajo de cURL. ¿Ves algo mal con el resultado del comando superior que publiqué arriba? – JSL