Un resultat SQL gran per VPN: on esperen les files

Les consultes poden acabar en mil·lisegons i tot i així trigar minuts a arribar a un portàtil per una VPN. El servidor escriu les files en buffers, la connexió les transporta i el client les consumeix, i aquestes etapes se superposen en lloc de funcionar en seqüència. Qualsevol d’elles pot esdevenir el límit. Trobeu l’etapa que realment espera abans de canviar l’amplada de banda o activar la compressió.

Tres etapes, un cronòmetre

Separeu el temporitzador en dos nombres amb significats diferents: el moment en què la primera fila està disponible i el moment en què s’ha consumit l’última fila. Una graella que pinta la primera pàgina només demostra que la consulta ha començat. El temps del resultat complet és el que l’usuari experimenta quan exporta o es desplaça fins al final.

Registreu els dos nombres amb el text de la consulta, els paràmetres i la configuració de connexió. Sense aquest context, la comparació és entre dues feines diferents, no entre dos llocs.

Llegiu l’espera abans de la xarxa

SQL Server escriu les files del resultat en buffers de sortida perquè el client les reculli, i un client que consumeix lentament pot fer que el servidor esperi en aquest enviament. El tipus d’espera és ASYNC_NETWORK_IO, i la nota de resolució de problemes de Microsoft inclou els resultats grans i el processament al costat del client entre les seves causes. L’espera us diu que el camí d’enviament està bloquejat, no per què.

Una VPN lenta hi pot contribuir, però també un client que formata cada fila, escriu en un fitxer o fa pauses entre lots. El nom de l’espera és un punter al següent mesurament, no un veredicte sobre l’enllaç.

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

Llegiu el comptador mentre s’executa la càrrega limitada, no després d’una hora inactiva, perquè els comptadors acumulatius barregen totes les sessions des que es va iniciar la instància. Compareu el delta durant l’execució en lloc del total de tota la vida. Un delta creixent durant la transferència estreny la pregunta cap al consum o el lliurament.

Poseu els dos clients al mateix rellotge

Executeu una càrrega limitada des d’un client a prop de la base de dades i des del client remot. Mantingueu idèntics la consulta, els paràmetres, la mida del resultat i la configuració de connexió. Feu servir el mateix mesurament als dos costats, perquè el temps d’execució del servidor, el temps de visualització de la graella i el temps d’exportació són tres rellotges diferents. Comparar un nombre del costat del servidor amb un temporitzador d’exportació del costat del client produeix una conclusió que no es pot provar.

Quan el camí sembli el responsable, feu que el propietari de la xarxa observi pèrdues, retransmissions i rendiment assolit per a aquest flux concret mentre dura la transferència. Una prova de velocitat genèrica pot utilitzar una altra ruta, un altre punt final o un altre patró de concurrència. Una petició petita que té èxit diu poc sobre una transferència de resultats sostinguda.

Retalleu bytes abans de culpar el camí

El filtratge, l’agregació i la selecció només de les columnes necessàries redueixen tant el volum de transferència com la feina que fa el client amb cada fila. Preserveu el resultat previst, perquè un informe pot necessitar detall que un resum en pantalla no té.

Per a exportacions repetibles, una ubicació d’execució aprovada a prop de la base de dades pot escriure una sortida definida que després es lliura una vegada. Això canvia el flux de treball i els seus controls d’accés, i no és permís per deixar un abocament sense restriccions en un amfitrió compartit.

La compressió no és la reparació per defecte. El suport i la seguretat depenen del protocol i del desplegament reals, i un flux comprimit que el client descomprimeix lentament pot empitjorar l’experiència. Mesureu primer l’etapa i després trieu un canvi admès per a aquesta etapa.