¿Cómo puedo aproximar el tiempo de conexión del proxy para una solicitud de CURL utilizando los valores de CURLINFO_*_TIME?

libcurl

Question

A continuación hay un pequeño conjunto de datos del cual intento responder dos preguntas:

1. ¿Cuánto tiempo tomó el proxy para conectarse al servidor API?
2. ¿Cuánto tiempo tardó la solicitud de la API en regresar?

El código básico se ve así:

$c = curl_init(); // assume all options set correctly
$time = microtime(true);
$response = curl_exec($c);
$curl_info = curl_getinfo($c); // Returns each `*_TIME` field
$response_time = microtime(true)-$time; // Returns total PHP execution time

De lo anterior, construyo esto:

id response_time NAMELOOKUP_TIME CONNECT_TIME APPCONNECT_TIME PRETRANSFER_TIME STARTTRANSFER_TIME REDIRECT_TIME TOTAL_TIME
1 0.250691 0.000191 0.025070 NULL 0.181040 0.250239 0.000000 0.250306
2 0.958577 0.000129 0.022764 NULL 0.136846 0.664099 0.000000 0.957881
3 0.578614 0.000053 0.021111 NULL 0.127998 0.440123 0.000000 0.577812

¿Cuánto tiempo se gastó en la solicitud de proxy contra solicitud de API para cada uno de los anteriores?

La documentación de cURL es útil, pero no estoy seguro de cómo responder mis preguntas anteriores con la sección relevante de los documentos:

TOTAL_TIME Total time of previous transfer.
NAMELOOKUP_TIME Time from start until name resolving completed.
CONNECT_TIME Time from start until remote host or proxy completed.
APPCONNECT_TIME Time from start until SSL/SSH handshake completed.
PRETRANSFER_TIME Time from start until just before the transfer begins.
STARTTRANSFER_TIME Time from start until just when the first byte is received.
REDIRECT_TIME Time taken for all redirect steps before the final transfer.

El cuadro incluido es útil para ver cómo se acumulan estos tiempos:

|
|--NAMELOOKUP
|--|--CONNECT
|--|--|--APPCONNECT
|--|--|--|--PRETRANSFER
|--|--|--|--|--STARTTRANSFER
|--|--|--|--|--|--TOTAL
|--|--|--|--|--|--REDIRECT

Pero todavía no estoy seguro de qué atribuir el tiempo de conexión del proxy. Aquí está el mismo cuadro con mis comentarios:

|
|--NAMELOOKUP // DNS, clearly not proxy. Also insignificant values.
|--|--CONNECT // Does this count toward Proxy Time?
|--|--|--APPCONNECT // Not set (likely due to non-https transaction)
|--|--|--|--PRETRANSFER // Does this count toward Proxy Time?
|--|--|--|--|--STARTTRANSFER // Stop proxy time? So Proxy Time = STARTTRANSFER?
|--|--|--|--|--|--TOTAL // Would TOTAL-STARTRANSFER = API Request Time?
|--|--|--|--|--|--REDIRECT // Always 0 (???)

Aquí hay una tabla de cómo funcionan los Proxies HTTP. ¿Dónde encajan los elementos anteriores de CURLINFO _ * _ TIME en esta tabla?

Answer 1

No creo que haya ninguna forma de calcular con precisión lo que estás buscando.

cURL se conecta al proxy, envía la solicitud y espera la respuesta. Todo lo que hace el proxy en el tiempo (su propia resolución de DNS, conectarse al host, enviar (proxying) la solicitud, esperar la respuesta, leer la respuesta y volver a enviarla por proxy es una caja negra para cURL.

No hay forma de saber por cuánto tiempo alguno de esos pasos tomó individualmente únicamente del proxy HTTP / SOCKS.

Lo único que puede saber con precisión es la suma de todas esas acciones ( CURLINFO_TOTAL_TIME - CURLINFO_STARTTRANSFER_TIME ). Supongo que incluso sería posible que haya un ligero retraso desde el momento en que el proxy finaliza la solicitud hasta cuando cURL recupera el primer byte (¿quizás el almacenamiento en caché?).

Otra posibilidad de la que no estoy seguro (podría depender de la configuración del proxy y los encabezados de respuesta enviados por la API) es cuando el proxy en realidad envía los datos nuevamente. Podría necesitar descargar toda la respuesta HTTP, o podría comenzar a enviar encabezados y datos a medida que los lee. Esto podría ocasionar algunas diferencias potencialmente significativas en sus cálculos.

En última instancia, creo que la conclusión es que no tiene detalles de conexión del proxy, no hay forma de saber o aproximar con precisión la duración de la conexión proxy a la API, y cuánto tiempo tomó obtener una respuesta. De lo contrario, tiene razón en que TOTAL - STARTTRANSFER es su mejor aproximación para el tiempo de respuesta si está usando un proxy.

Sin saber exactamente lo que intenta hacer o por qué, tal vez su mejor opción sea arrendar algunas instancias de VPS o de nube en varias ubicaciones geográficas para ejecutar algunas instancias de PHP usando cURL para conectarse directamente a la API, de modo que tenga acceso a todas las las métricas que estás buscando