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

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

Symptomet er en skjerm, ikke en spørring

Alle spørringene på den skjermen kan være raske, og skjermen kan likevel være treg, fordi summen er summen av ventetider og ikke summen av kjøretider. En setning som kjører på to millisekunder koster likevel en hel rundtur når klienten må motta resultatet før den sender den neste. På en linje med førti millisekunder forsinkelse blir hundre avhengige kall til omtrent fire sekunder før noe tegning i det hele tatt begynner. Regnestykket er en modell av ventingen, ikke en måling av linjen din.

Det er derfor en hastighetstest ser uskyldig ut. Bulkoverføring måler gjennomstrømning, et snakkesalig skjema måler forsinkelse, og en VPN kan være utmerket på det ene og helt alminnelig på det andre. Å diagnostisere skjermen betyr derfor å måle skjermen og ikke linjen.

Skriv ned tiden fra start til slutt for én brukerhandling før du endrer noe. Det tallet er den eneste referansen som kan si om en senere rettelse virket.

Tell sekvensielle ventetider i én brukerhandling

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

Forskjellen mellom de 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 forskjellene i stedet for kjøretidene.

Skriv resultatet ned som et antall sekvensielle ventetider. Det er størrelsen de to neste avsnittene kan redusere, og det er et tall du kan krangle om med bevis.

Samle de uavhengige kallene, behold de avhengige

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

Settbasert arbeid fjerner ventetider grundigere enn samling. É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 å se over.

En samling må fortsatt bevare feilhåndtering og transaksjonsgrenser. Å lime urelaterte setninger sammen til én streng er ikke en trygg optimalisering, og en samling som skjuler en mislykket setning bak en vellykket innsending er verre enn ventetidene 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 linje 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 og ikke én gang per kall.

I ADO.NET gir lukking eller dispose av en poolert tilkobling den tilbake for gjenbruk i stedet for å åpne en ny fysisk, så mønsteret som ligner en lekkasje er ofte riktig bruk. Kontroller at poolen virkelig 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. Ytelsesveiledningen for SQL sier det samme om å redusere rundturer og samle hyppige ad hoc-kall, med tjenestespesifikke eksempler du bør knytte til din egen utrulling.

Pooling fjerner oppsettkostnaden og lar de serielle spørringsventetidene være i fred. Det er en forutsetning for en ren måling, ikke en rettelse 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 snakkesalig arbeidslast kan det være en stor endring, og det er en driftsendring like mye som en ytelsesendring: sesjonsstyring, tilgangskontroll, programvaredistribusjon og brukeropplevelse flytter alle sammen med applikasjonen.

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

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