Per què una aplicació SQL xerraire s'arrossega per una VPN i què cal agrupar

Un formulari que a la xarxa local es mostra en menys d'un segon triga cinc segons per una VPN, mentre que una còpia de fitxer al mateix enllaç va a tota velocitat. La diferència no és l'amplada de banda. El formulari espera una seqüència de respostes i paga l'anada i tornada completa a cada pas, mentre que la còpia de fitxer manté els bytes en moviment de manera contínua. Compta aquestes esperes abans de tocar la línia d'accés.

El símptoma és una pantalla, no una consulta

Cada consulta d'aquella pantalla pot ser ràpida i la pantalla pot continuar sent lenta, perquè el total és la suma d'esperes i no la suma de temps d'execució. Una sentència que s'executa en dos mil·lisegons encara costa una anada i tornada completa quan el client ha de rebre'n el resultat abans d'enviar la següent. En un camí amb quaranta mil·lisegons de latència, cent crides dependents sumen uns quatre segons abans que comenci cap treball de renderització. Aquesta aritmètica és un model de l'espera, no una mesura del teu enllaç.

Per això una prova de velocitat sembla innocent. La transferència massiva mesura el cabal, un formulari xerraire mesura la latència, i una VPN pot ser excel·lent en una cosa i ordinària en l'altra. Per tant, diagnosticar la pantalla vol dir mesurar la pantalla i no l'enllaç.

Registra el temps d'extrem a extrem d'una acció d'usuari abans de canviar res. Aquest número és l'única línia base que et pot dir si una correcció posterior ha funcionat.

Compta les esperes seqüencials en una acció d'usuari

Instrumenta el client en lloc d'endevinar. A psql, \timing on imprimeix el temps transcorregut de cada sentència, i EXPLAIN (ANALYZE, BUFFERS) mostra quant d'aquest temps ha gastat realment el servidor en la feina.

La diferència entre aquests dos números és la teva sobrecàrrega de xarxa i de client. Si una sentència s'executa en dos mil·lisegons i el client n'enregistra seixanta, els cinquanta-vuit restants són viatge i processament local, i cap índex no els eliminarà. Repeteix aquesta comparació per a cada sentència que emet la pantalla i suma les diferències en lloc dels temps d'execució.

Anota el resultat com un recompte d'esperes seqüencials. Aquesta és la quantitat que les dues seccions següents poden reduir, i és un número que pots discutir amb proves.

Agrupa les crides independents, conserva les dependents

Dues sentències que no llegeixen els resultats l'una de l'altra poden viatjar juntes i recollir-se una sola vegada, cosa que converteix dues esperes en una. Dues sentències en què la segona necessita el valor de la primera no poden, perquè la dependència és real i agrupar-les canviaria què fa el programa. Classifica les crides en aquestes dues piles abans de reescriure res, i la mida de cada pila et diu què és possible.

La feina basada en conjunts elimina esperes més a fons que l'agrupació. Una consulta que retorna les files que un bucle anava recollint d'una en una elimina el bucle i també les anades i tornades. Busca primer el bucle, perquè normalment és el guany més gran i el canvi més fàcil de revisar.

Una agrupació encara ha de preservar el tractament d'errors i les fronteres de transacció. Concatenar sentències sense relació en una sola cadena no és una optimització segura, i una agrupació que amaga una sentència fallida darrere d'un enviament correcte és pitjor que les esperes que ha estalviat.

Reutilitza les connexions abans de comprar amplada de banda

Una connexió nova costa resolució de noms, un handshake TCP, negociació TLS i autenticació, i en un camí d'alta latència cadascun d'aquests és una altra anada i tornada abans que s'executi la primera consulta. Els pools de connexions existeixen per pagar aquest cost una vegada per procés i no una vegada per crida.

A ADO.NET, tancar o alliberar una connexió del pool la retorna per reutilitzar-la en lloc d'obrir-ne una de física nova, així que el patró que sembla una fuita sovint és l'ús correcte. Verifica que el pool s'estigui fent servir de veritat en lloc de suposar-ho: registra la creació de connexions físiques o observa el nombre de sessions al servidor mentre la pantalla funciona. Les pautes de rendiment de SQL diuen el mateix sobre reduir anades i tornades i agrupar les crides ad hoc freqüents, amb exemples específics del servei que hauries de mapar a la teva implementació.

L'agrupació elimina el cost de configuració i deixa intactes les esperes seqüencials de les consultes. És un requisit previ per a una mesura neta, no una correcció per si sola.

Pondera moure l'execució més a prop de les dades

Executar l'aplicació a prop de la base de dades substitueix molts intercanvis remots amb la base per una sola sessió de pantalla remota. Per a una càrrega xerraire pot ser un canvi gran, i és un canvi operatiu tant com un canvi de rendiment: la gestió de sessions, el control d'accés, el desplegament de programari i l'experiència d'usuari es mouen tots amb l'aplicació.

Mesura la interfície real i les dades que transfereix abans de suposar que qualsevol direcció és més ràpida. Una sessió d'escriptori remot mou píxels, i una pantalla amb gràfics densos pot funcionar pitjor pel mateix camí que les consultes que ha substituït, sobretot quan el client redibuixa contínuament.

Després repeteix l'acció original i compara tres números: esperes seqüencials, volum de resultats i temps de finalització d'extrem a extrem. Una millora que canvia la tasca d'usuari mesurada tot preservant la correcció de les dades i la política d'accés és la que val la pena conservar.