Un grande risultato SQL attraverso una VPN: dove aspettano le righe

Le query possono terminare in millisecondi e impiegare comunque minuti per raggiungere un portatile attraverso una VPN. Il server scrive le righe nei buffer, la connessione le trasporta e il client le consuma, e queste fasi si sovrappongono invece di svolgersi in sequenza. Ognuna di esse può diventare il limite. Trovate la fase che aspetta davvero prima di cambiare larghezza di banda o attivare la compressione.

Tre fasi, un cronometro

Dividete il timer in due numeri dal significato diverso: il momento in cui la prima riga è disponibile e il momento in cui l’ultima riga è stata consumata. Una griglia che disegna la prima pagina prova solo che la query è iniziata. Il tempo del risultato completo è quello che l’utente vive quando esporta o scorre fino alla fine.

Annotate entrambi i numeri con il testo della query, i parametri e le impostazioni di connessione. Senza questo contesto il confronto è tra due lavori diversi, non tra due posizioni.

Leggete l’attesa prima della rete

SQL Server scrive le righe del risultato in buffer di output perché il client le recuperi, e un client che consuma lentamente può far attendere il server su quell’invio. Il tipo di attesa è ASYNC_NETWORK_IO, e la nota di risoluzione dei problemi di Microsoft elenca i risultati di grandi dimensioni e l’elaborazione lato client tra le cause. L’attesa dice che il percorso di invio è bloccato, non perché.

Una VPN lenta può contribuire, ma anche un client che formatta ogni riga, scrive su un file o fa pause tra i lotti. Il nome dell’attesa è un puntatore alla misurazione successiva, non un verdetto sul collegamento.

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

Leggete il contatore mentre il carico di lavoro limitato è in esecuzione, non dopo un’ora di inattività, perché i contatori cumulativi mescolano ogni sessione dall’avvio dell’istanza. Confrontate il delta durante l’esecuzione invece del totale dell’intera vita. Un delta crescente durante il trasferimento restringe la domanda al consumo o alla consegna.

Mettete entrambi i client sullo stesso orologio

Eseguite un carico di lavoro limitato da un client vicino al database e dal client remoto. Mantenete identici query, parametri, dimensione del risultato e impostazioni di connessione. Usate la stessa misurazione su entrambi i lati, perché il tempo di esecuzione del server, il tempo di visualizzazione della griglia e il tempo di esportazione sono tre orologi diversi. Confrontare un numero lato server con un timer di esportazione lato client produce una conclusione che non può essere verificata.

Quando il percorso sembra responsabile, chiedete al responsabile della rete di osservare perdite, ritrasmissioni e throughput raggiunto per quel flusso specifico mentre il trasferimento è in corso. Un test di velocità generico può usare un’altra rotta, un altro endpoint o un altro schema di concorrenza. Una piccola richiesta riuscita dice poco su un trasferimento di risultati prolungato.

Tagliate i byte prima di dare la colpa al percorso

Il filtro, l’aggregazione e la selezione delle sole colonne necessarie riducono sia il volume trasferito sia il lavoro che il client fa su ogni riga. Preservate il risultato previsto, perché un report può aver bisogno di dettagli che un riepilogo a schermo non ha.

Per esportazioni ripetibili, una posizione di esecuzione approvata vicino al database può scrivere un output definito che viene poi consegnato una volta. Questo cambia il flusso di lavoro e i suoi controlli di accesso, e non è un permesso per lasciare un dump senza restrizioni su un host condiviso.

La compressione non è la riparazione predefinita. Supporto e sicurezza dipendono dal protocollo e dalla distribuzione reali, e un flusso compresso che il client decomprime lentamente può peggiorare l’esperienza. Misurate prima la fase, poi scegliete una modifica supportata per quella fase.