Un rezultat SQL mare prin VPN: unde așteaptă rândurile

Interogările se pot termina în milisecunde și totuși pot dura minute până ajung la un laptop printr-o VPN. Serverul scrie rânduri în buffere, conexiunea le transportă și clientul le consumă, iar aceste etape se suprapun în loc să ruleze succesiv. Oricare dintre ele poate deveni limita. Găsiți etapa care așteaptă cu adevărat înainte de a schimba lățimea de bandă sau de a activa compresia.

Trei etape, un cronometru

Împărțiți cronometrul în două numere cu semnificații diferite: momentul în care primul rând este disponibil și momentul în care ultimul rând a fost consumat. O grilă care desenează prima pagină dovedește doar că interogarea a început. Timpul rezultatului complet este ceea ce trăiește utilizatorul când exportă sau derulează până la sfârșit.

Notați ambele numere împreună cu textul interogării, parametrii și setările conexiunii. Fără acest context, comparația este între două lucrări diferite, nu între două locații.

Citiți așteptarea înaintea rețelei

SQL Server scrie rândurile rezultatului în buffere de ieșire pe care clientul le preia, iar un client care consumă lent poate face serverul să aștepte la acea trimitere. Tipul de așteptare este ASYNC_NETWORK_IO, iar nota de depanare a Microsoft enumeră rezultatele mari și procesarea pe partea clientului printre cauze. Așteptarea spune că calea de trimitere este blocată, nu de ce.

O VPN lentă poate contribui, dar și un client care formatează fiecare rând, scrie într-un fișier sau face pauze între loturi. Numele așteptării este un indicator către următoarea măsurătoare, nu o sentință despre legătură.

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

Citiți contorul în timp ce sarcina limitată rulează, nu după o oră inactivă, deoarece contoarele cumulative amestecă fiecare sesiune de la pornirea instanței. Comparați diferența pe durata rulării, nu totalul pe toată viața. O diferență crescătoare în timpul transferului restrânge întrebarea la consum sau livrare.

Puneți ambii clienți pe același ceas

Rulați o sarcină limitată de la un client aproape de baza de date și de la clientul la distanță. Păstrați identice interogarea, parametrii, dimensiunea rezultatului și setările conexiunii. Folosiți aceeași măsurătoare pe ambele părți, deoarece timpul de execuție al serverului, timpul de afișare al grilei și timpul de export sunt trei ceasuri diferite. Compararea unui număr din partea serverului cu un cronometru de export din partea clientului produce o concluzie care nu poate fi testată.

Când calea pare responsabilă, rugați proprietarul rețelei să urmărească pierderile, retransmisiile și debitul obținut pentru acel flux specific în timpul transferului. Un test generic de viteză poate folosi altă rută, alt punct final sau alt model de concurență. O cerere mică reușită spune puțin despre un transfer susținut de rezultate.

Tăiați octeții înainte de a învinui calea

Filtrarea, agregarea și selectarea doar a coloanelor necesare reduc atât volumul transferului, cât și munca pe care clientul o face cu fiecare rând. Păstrați rezultatul dorit, deoarece un raport poate avea nevoie de detalii pe care un rezumat de pe ecran nu le are.

Pentru exporturi repetabile, o locație de execuție aprobată lângă baza de date poate scrie o ieșire definită care apoi este livrată o dată. Aceasta schimbă fluxul de lucru și controalele sale de acces și nu este permisiunea de a lăsa un dump nerestricționat pe un gazdă partajată.

Compresia nu este reparația implicită. Suportul și securitatea depind de protocolul și implementarea reale, iar un flux comprimat pe care clientul îl decomprimă lent poate înrăutăți experiența. Măsurați mai întâi etapa, apoi alegeți o modificare acceptată pentru acea etapă.