Um grande resultado SQL pela VPN: onde as linhas esperam

As consultas podem terminar em milissegundos e ainda levar minutos para chegar a um portátil através de uma VPN. O servidor escreve linhas em buffers, a conexão transporta-as e o cliente consome-as, e essas etapas sobrepõem-se em vez de decorrerem em sequência. Qualquer uma delas pode tornar-se o limite. Encontre a etapa que está realmente à espera antes de mudar a largura de banda ou ativar a compressão.

Três etapas, um cronómetro

Divida o temporizador em dois números com significados diferentes: o momento em que a primeira linha está disponível e o momento em que a última linha foi consumida. Uma grelha que desenha a primeira página prova apenas que a consulta começou. O tempo do resultado completo é o que o utilizador vive quando exporta ou desliza até ao fim.

Registe os dois números com o texto da consulta, os parâmetros e as definições de ligação. Sem esse contexto, a comparação é entre dois trabalhos diferentes, não entre dois locais.

Leia a espera antes da rede

O SQL Server escreve as linhas do resultado em buffers de saída para o cliente as recolher, e um cliente que consome devagar pode fazer o servidor esperar nesse envio. O tipo de espera é ASYNC_NETWORK_IO, e a nota de resolução de problemas da Microsoft inclui os resultados grandes e o processamento do lado do cliente entre as causas. A espera diz que o caminho de envio está bloqueado, não porquê.

Uma VPN lenta pode contribuir, mas também um cliente que formata cada linha, escreve num ficheiro ou faz pausas entre lotes. O nome da espera é um ponteiro para a medição seguinte, não um veredicto sobre a ligação.

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

Leia o contador enquanto a carga de trabalho limitada decorre, não após uma hora inativa, porque os contadores cumulativos misturam todas as sessões desde o arranque da instância. Compare o delta ao longo da execução em vez do total de vida. Um delta crescente durante a transferência estreita a questão para o consumo ou a entrega.

Coloque os dois clientes no mesmo relógio

Execute uma carga de trabalho limitada a partir de um cliente próximo da base de dados e do cliente remoto. Mantenha idênticos a consulta, os parâmetros, o tamanho do resultado e as definições de ligação. Use a mesma medição dos dois lados, porque o tempo de execução do servidor, o tempo de visualização da grelha e o tempo de exportação são três relógios diferentes. Comparar um número do lado do servidor com um temporizador de exportação do lado do cliente produz uma conclusão que não pode ser testada.

Quando o caminho parecer responsável, peça ao responsável da rede para observar perdas, retransmissões e débito alcançado para esse fluxo específico enquanto a transferência decorre. Um teste de velocidade genérico pode usar outra rota, ponto final ou padrão de concorrência. Um pequeno pedido bem-sucedido diz pouco sobre uma transferência de resultados sustentada.

Corte bytes antes de culpar o caminho

A filtragem, a agregação e a seleção apenas das colunas necessárias reduzem tanto o volume de transferência como o trabalho que o cliente faz com cada linha. Preserve o resultado pretendido, porque um relatório pode precisar de detalhe que um resumo no ecrã não tem.

Para exportações repetíveis, um local de execução aprovado perto da base de dados pode escrever uma saída definida que depois é entregue uma vez. Isso altera o fluxo de trabalho e os seus controlos de acesso, e não é permissão para deixar um dump sem restrições num anfitrião partilhado.

A compressão não é a reparação padrão. O suporte e a segurança dependem do protocolo e da implementação reais, e um fluxo comprimido que o cliente descomprime devagar pode piorar a experiência. Meça primeiro a etapa e depois escolha uma alteração suportada para essa etapa.