Un resultado SQL grande por VPN: dónde esperan las filas

Las consultas pueden terminar en milisegundos y aun así tardar minutos en llegar a un portátil por una VPN. El servidor produce filas en búferes, la conexión las transporta y el cliente las consume, y esas etapas se solapan en lugar de ejecutarse en secuencia. Cualquiera de ellas puede convertirse en el límite. Encuentre la etapa que realmente espera antes de cambiar el ancho de banda o activar la compresión.

Tres etapas, un cronómetro

Divida el temporizador en dos números con significados distintos: el momento en que la primera fila está disponible y el momento en que se ha consumido la última. Una cuadrícula que pinta la primera página solo demuestra que la consulta empezó. El tiempo del resultado completo es lo que experimenta el usuario cuando exporta o se desplaza hasta el final.

Anote ambos números con el texto de la consulta, los parámetros y la configuración de conexión. Sin ese contexto, la comparación es entre dos trabajos distintos, no entre dos ubicaciones.

Lea la espera antes de la red

SQL Server escribe las filas del resultado en búferes de salida para que el cliente las recupere, y un cliente que consume despacio puede hacer que el servidor espere en ese envío. El tipo de espera es ASYNC_NETWORK_IO, y la nota de solución de problemas de Microsoft incluye los resultados grandes y el procesamiento en el lado del cliente entre sus causas. La espera indica que la ruta de envío está bloqueada, no por qué.

Una VPN lenta puede contribuir, pero también un cliente que formatea cada fila, escribe en un archivo o hace pausas entre lotes. El nombre de la espera es una pista hacia la siguiente medición, no un veredicto sobre el enlace.

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

Lea el contador mientras se ejecuta la carga limitada, no después de una hora inactiva, porque los contadores acumulativos mezclan todas las sesiones desde que se inició la instancia. Compare el delta durante la ejecución en lugar del total de por vida. Un delta creciente durante la transferencia reduce la pregunta al consumo o la entrega.

Ponga ambos clientes en el mismo reloj

Ejecute una carga limitada desde un cliente cercano a la base de datos y desde el cliente remoto. Mantenga idénticos la consulta, los parámetros, el tamaño del resultado y la configuración de conexión. Use la misma medición en ambos lados, porque el tiempo de ejecución del servidor, el tiempo de visualización de la cuadrícula y el tiempo de exportación son tres relojes distintos. Comparar un número del lado del servidor con un temporizador de exportación del lado del cliente produce una conclusión que no se puede probar.

Cuando la ruta parezca responsable, pida al responsable de la red que vigile pérdidas, retransmisiones y rendimiento alcanzado para ese flujo concreto mientras dura la transferencia. Una prueba de velocidad genérica puede usar otra ruta, otro punto final u otro patrón de concurrencia. Una petición pequeña y exitosa dice poco sobre una transferencia de resultados sostenida.

Recorte bytes antes de culpar a la ruta

El filtrado, la agregación y la selección solo de las columnas necesarias reducen tanto el volumen de transferencia como el trabajo que hace el cliente con cada fila. Preserve el resultado previsto, porque un informe puede necesitar detalle que un resumen en pantalla no tiene.

Para exportaciones repetibles, una ubicación de ejecución aprobada cerca de la base de datos puede escribir una salida definida que luego se entrega una vez. Eso cambia el flujo de trabajo y sus controles de acceso, y no es permiso para dejar un volcado sin restricciones en un host compartido.

La compresión no es la reparación predeterminada. El soporte y la seguridad dependen del protocolo y del despliegue reales, y un flujo comprimido que el cliente descomprime despacio puede empeorar la experiencia. Mida primero la etapa y después elija un cambio admitido para esa etapa.