Un resultado SQL grande por VPN: onde esperan as filas

As consultas poden rematar en milisegundos e aínda así tardar minutos en chegar a un portátil por unha VPN. O servidor produce filas en buffers, a conexión transpórtase e o cliente consómeas, e esas etapas solápanse en lugar de executarse en secuencia. Calquera delas pode converterse no límite. Atope a etapa que realmente espera antes de cambiar o ancho de banda ou activar a compresión.

Tres etapas, un cronómetro

Divida o temporizador en dous números con significados distintos: o momento en que a primeira fila está dispoñible e o momento en que se consumiu a última. Unha grella que pinta a primeira páxina só demostra que a consulta comezou. O tempo do resultado completo é o que experimenta o usuario cando exporta ou despraza ata o final.

Anote ambos os números co texto da consulta, os parámetros e a configuración de conexión. Sen ese contexto, a comparación é entre dous traballos distintos, non entre dúas localizacións.

Lea a espera antes da rede

SQL Server escribe as filas do resultado en buffers de saída para que o cliente as recolla, e un cliente que consume amodo pode facer que o servidor espere nese envío. O tipo de espera é ASYNC_NETWORK_IO, e a nota de solución de problemas de Microsoft inclúe os resultados grandes e o procesamento no lado do cliente entre as súas causas. A espera indica que a ruta de envío está bloqueada, non por que.

Unha VPN lenta pode contribuír, pero tamén un cliente que formatea cada fila, escribe nun ficheiro ou fai pausas entre lotes. O nome da espera é un punteiro cara á seguinte medición, non un veredicto sobre a ligazón.

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

Lea o contador mentres se executa a carga limitada, non despois dunha hora inactiva, porque os contadores acumulativos mesturan todas as sesións desde que se iniciou a instancia. Compare o delta durante a execución en lugar do total de toda a vida. Un delta crecente durante a transferencia reduce a pregunta ao consumo ou á entrega.

Pon os dous clientes no mesmo reloxo

Execute unha carga limitada desde un cliente próximo á base de datos e desde o cliente remoto. Manteña idénticos a consulta, os parámetros, o tamaño do resultado e a configuración de conexión. Use a mesma medición nos dous lados, porque o tempo de execución do servidor, o tempo de visualización da grella e o tempo de exportación son tres reloxos distintos. Comparar un número do lado do servidor cun temporizador de exportación do lado do cliente produce unha conclusión que non se pode probar.

Cando a ruta pareza responsable, pida ao responsable da rede que vixíe perdas, retransmisións e rendemento acadado para ese fluxo concreto mentres dura a transferencia. Unha proba de velocidade xenérica pode usar outra ruta, outro punto final ou outro patrón de concorrencia. Unha petición pequena e exitosa di pouco sobre unha transferencia de resultados sostida.

Recorte bytes antes de culpar a ruta

O filtrado, a agregación e a selección só das columnas necesarias reducen tanto o volume de transferencia como o traballo que fai o cliente con cada fila. Preserve o resultado previsto, porque un informe pode necesitar detalle que un resumo en pantalla non ten.

Para exportacións repetibles, unha localización de execución aprobada preto da base de datos pode escribir unha saída definida que despois se entrega unha vez. Iso cambia o fluxo de traballo e os seus controis de acceso, e non é permiso para deixar un volcado sen restricións nun host compartido.

A compresión non é a reparación predeterminada. O soporte e a seguridade dependen do protocolo e do despregamento reais, e un fluxo comprimido que o cliente descomprime amodo pode empeorar a experiencia. Mida primeiro a etapa e despois escolla un cambio admitido para esa etapa.