Hvorfor en snakkesalig SQL-app kravler over en VPN, og hvad du skal samle i batches

En formular, der vises på under et sekund på et LAN, tager fem sekunder over en VPN, mens en filkopi på samme forbindelse kører med fuld hastighed. Forskellen er ikke båndbredde. Formularen venter på en række svar og betaler hele rundturen ved hvert trin, mens filkopien holder bytes i bevægelse hele tiden. Tæl de ventetider, før du rører adgangslinjen.

Symptomet er en skærm, ikke en forespørgsel

Hver forespørgsel på den skærm kan være hurtig, og skærmen kan stadig være langsom, fordi totalen er summen af ventetider og ikke summen af udførelsestider. En sætning, der kører på to millisekunder, koster stadig en hel rundtur, når klienten skal modtage resultatet, før den sender den næste. På en vej med fyrre millisekunders latenstid løber hundrede afhængige kald op i omkring fire sekunder, før noget tegne-arbejde begynder. Den aritmetik er en model af ventetiden, ikke en måling af din forbindelse.

Derfor ser en hastighedstest uskyldig ud. Bulkoverførsel måler gennemstrømning, en snakkesalig formular måler latenstid, og en VPN kan være fremragende til det ene og almindelig til det andet. At diagnosticere skærmen betyder derfor at måle skærmen og ikke forbindelsen.

Noter den end-to-end tid for én brugerhandling, før du ændrer noget. Det tal er den eneste baseline, der kan fortælle, om en senere rettelse virkede.

Tæl sekventielle ventetider i én brugerhandling

Instrumentér klienten i stedet for at gætte. I psql udskriver \timing on den forløbne tid for hver sætning, og EXPLAIN (ANALYZE, BUFFERS) viser, hvor meget af den tid serveren faktisk brugte på arbejdet.

Forskellen mellem de to tal er din netværks- og klientomkostning. Hvis en sætning udføres på to millisekunder, og klienten registrerer tres, er de resterende otteoghalvtreds rejse og lokal behandling, og ingen indeks fjerner dem. Gentag den sammenligning for hver sætning, skærmen udsender, og læg forskellene sammen i stedet for udførelsestiderne.

Skriv resultatet ned som et antal sekventielle ventetider. Det er den mængde, de næste to afsnit kan reducere, og det er et tal, du kan argumentere for med bevis.

Saml de uafhængige kald, behold de afhængige

To sætninger, der ikke læser hinandens resultater, kan rejse sammen og hentes én gang, hvilket gør to ventetider til én. To sætninger, hvor den anden har brug for værdien fra den første, kan ikke, fordi afhængigheden er reel, og batching ville ændre, hvad programmet gør. Sortér kaldene i de to bunker, før du omskriver noget, og størrelsen på hver bunke fortæller dig, hvad der er muligt.

Sætbaseret arbejde fjerner ventetider mere grundigt end batching. Én forespørgsel, der returnerer de rækker, som en løkke hentede én ad gangen, eliminerer både løkken og rundturene. Led efter løkken først, fordi den normalt er den største gevinst og den nemmere ændring at gennemgå.

En batch skal stadig bevare fejlhåndtering og transaktionsgrænser. At kæde urelaterede sætninger sammen i én streng er ikke en sikker optimering, og en batch, der skjuler en mislykket sætning bag en vellykket indsendelse, er værre end de ventetider, den sparede.

Genbrug forbindelser, før du køber båndbredde

En ny forbindelse koster navneoversættelse, et TCP-håndtryk, TLS-forhandling og godkendelse, og på en vej med høj latenstid er hver af dem endnu en rundtur, før den første forespørgsel kører. Forbindelsespuljer findes for at betale den pris én gang pr. proces i stedet for én gang pr. kald.

I ADO.NET returnerer lukning eller bortskaffelse af en puljet forbindelse den til genbrug i stedet for at åbne en ny fysisk, så det mønster, der ligner en lækage, ofte er den korrekte brug. Bekræft, at puljen faktisk bruges, i stedet for at antage det: log oprettelsen af fysiske forbindelser, eller hold øje med sessionstallet på serveren, mens skærmen kører. Retningslinjerne for SQL-ydeevne siger det samme om at reducere rundture og samle hyppige ad hoc-kald, med tjenestespecifikke eksempler, som du bør overføre til din egen udrulning.

Puljning fjerner opsætningsomkostningen og lader sekventielle forespørgselsventetider være urørte. Det er en forudsætning for en ren måling, ikke en rettelse i sig selv.

Afvej at flytte udførelsen tættere på dataene

At køre applikationen tæt på databasen erstatter mange fjernudvekslinger med databasen med én fjernskærmsession. For en snakkesalig belastning kan det være en stor ændring, og det er en driftsændring lige så meget som en ydeevneændring: sessionsstyring, adgangskontrol, softwareudrulning og brugeroplevelse flytter alle med applikationen.

Mål den faktiske grænseflade og de data, den overfører, før du antager, at nogen retning er hurtigere. En fjernskrivebordssession flytter pixels, og en skærm med tæt grafik kan klare sig dårligere over samme vej end de forespørgsler, den erstattede, især når klienten tegner igen hele tiden.

Gentag derefter den oprindelige handling, og sammenlign tre tal: sekventielle ventetider, resultatvolumen og samlet færdiggørelsestid. En forbedring, der ændrer den målte brugergøremål, samtidig med at den bevarer datakorrekthed og adgangspolitik, er den, der er værd at beholde.