Hvorfor en pratsom SQL-app kryper over VPN, og hva du bør samle i batcher

Et skjema som åpnes på under ett sekund på et lokalnett bruker fem sekunder over VPN, mens en filkopi på samme linje går for full hastighet. Forskjellen er ikke båndbredde. Skjemaet venter på en sekvens av svar og betaler hele rundturen ved hvert steg, mens filkopien holder byte kontinuerlig i flukt. Tell disse ventingene før du rører aksesslinjen.

Symptomet er en skjerm, ikke en spørring

Hver spørring på den skjermen kan være rask, og skjermen kan fortsatt være treg, fordi totalen er summen av ventinger og ikke summen av utførelsestider. En setning som kjører på to millisekunder koster fortsatt en hel rundtur når klienten må motta resultatet før den sender den neste. På en vei med førti millisekunder forsinkelse summerer hundre avhengige kall seg til omtrent fire sekunder før noe tegne-arbeid skjer. Denne aritmetikken er en modell av ventingen, ikke en måling av linjen din.

Derfor ser en hastighetstest uskyldig ut. Massetransport måler gjennomstrømning, et pratsomt skjema måler forsinkelse, og en VPN kan være utmerket på det ene og samtidig helt vanlig på det andre. Å diagnostisere skjermen betyr derfor å måle skjermen og ikke linjen.

Registrer tiden fra ende til ende for én brukerhandling før du endrer noe. Det tallet er den eneste referansen som kan fortelle deg om en senere retting virket.

Tell sekvensielle vendinger i én brukerhandling

Instrumenter klienten i stedet for å gjette. I psql skriver \timing on ut medgått tid for hver setning, og EXPLAIN (ANALYZE, BUFFERS) viser hvor mye av den tiden serveren faktisk brukte på arbeidet.

Avstanden mellom disse to tallene er nettverks- og klientkostnaden din. Hvis en setning kjører på to millisekunder og klienten registrerer seksti, er de resterende femtiåtte reise og lokal behandling, og ingen indeks fjerner dem. Gjenta sammenligningen for hver setning skjermen sender, og summer avstandene i stedet for utførelsestidene.

Skriv ned resultatet som et antall sekvensielle vendinger. Det er mengden de to neste avsnittene kan redusere, og det er et tall du kan argumentere for med bevis.

Samle de uavhengige kallene, behold de avhengige

To setninger som ikke leser hverandres resultat kan reise sammen og samles inn én gang, noe som gjør to vendinger til én. To setninger der den andre trenger verdien fra den første kan ikke, fordi avhengigheten er reell og batching ville endre det programmet gjør. Sorter kallene i de to haugene før du skriver om noe, og størrelsen på hver haug forteller deg hva som er mulig.

Settbasert arbeid fjerner vendinger grundigere enn batching. Én spørring som returnerer radene en løkke hentet én om gangen, fjerner løkken så vel som rundturene. Se etter løkken først, fordi den vanligvis er den største gevinsten og den enkleste endringen å gjennomgå.

En batch må fortsatt bevare feilhåndtering og transaksjonsgrenser. Å sette sammen urelaterte setninger til én streng er ikke en trygg optimalisering, og en batch som skjuler en mislykket setning bak en vellykket innsending er verre enn vendingene den sparte.

Gjenbruk tilkoblinger før du kjøper båndbredde

En ny tilkobling koster navneoppslag, TCP-håndtrykk, TLS-forhandling og autentisering, og på en vei med høy forsinkelse er hver av dem nok en rundtur før den første spørringen kjører. Tilkoblingspooler finnes for å betale den kostnaden én gang per prosess i stedet for én gang per kall.

I ADO.NET returnerer lukking eller dispose av en poolert tilkobling den for gjenbruk i stedet for å åpne en ny fysisk, så mønsteret som ser ut som en lekkasje er ofte riktig bruk. Verifiser at poolen faktisk er i bruk i stedet for å anta det: logg oppretting av fysiske tilkoblinger, eller følg med på sesjonsantallet på serveren mens skjermen kjører. SQL-ytelsesveiledningen sier det samme om å redusere rundturer og å batch-e hyppige ad hoc-kall, med tjenestespesifikke eksempler du bør koble til din egen utrulling.

Pooling fjerner oppsettkostnaden og lar de serielle spørringsventingene være urørt. Det er en forutsetning for en ren måling, ikke en retting i seg selv.

Vurder å flytte utførelsen nærmere dataene

Å kjøre applikasjonen nær databasen erstatter mange eksterne databaseutvekslinger med én ekstern visningsøkt. For en pratsom arbeidsbelastning kan det være en stor endring, og det er en driftsendring like mye som en ytelsesendring: sesjonsstyring, tilgangskontroll, programvaredistribusjon og brukeropplevelse flytter alle med applikasjonen.

Mål det faktiske grensesnittet og dataene det overfører før du antar at noen retning er raskere. En ekstern skrivebordsøkt flytter piksler, og en skjerm med tett grafikk kan yte dårligere over samme vei enn spørringene den erstattet, spesielt når klienten tegner på nytt kontinuerlig.

Gjenta så den opprinnelige handlingen og sammenlign tre tall: sekvensielle vendinger, resultatvolum og fullføringstid fra ende til endi. En forbedring som endrer den målte brukeroppgaven mens den bevarer datakorrekthet og tilgangspolicy, er den som er verdt å beholde.