Kvifor ein pratsam SQL-app kryp over ein VPN, og kva du bør samle i batcher

Eit skjema som opnar på under eitt sekund på eit lokalnett brukar fem sekund over ein VPN, medan ein filkopi på same linja går for full fart. Skilnaden er ikkje bandbreidd. Skjemaet ventar på ein sekvens av svar og betaler heile rundturen ved kvart steg, medan filkopien held byte kontinuerleg i flukt. Tel desse ventingane før du rører aksesslinja.

Symptomet er ein skjerm, ikkje ei spørjing

Kvar spørjing på den skjermen kan vere rask, og skjermen kan framleis vere treg, fordi totalen er summen av ventingar og ikkje summen av utføringstider. Ei setning som køyrer på to millisekund kostar framleis ein heil rundtur når klienten må ta imot resultatet før han sender den neste. På ein veg med førti millisekund forseinking summerer hundre avhengige kall seg til om lag fire sekund før noko teiknearbeid skjer. Denne aritmetikken er ein modell av ventinga, ikkje ei måling av linja di.

Derfor ser ein hastigheitstest uskuldig ut. Massetransport måler gjennomstrøyming, eit pratsamt skjema måler forseinking, og ein VPN kan vere framifrå på det eine og samtidig heilt vanleg på det andre. Å diagnostisere skjermen tyder derfor å måle skjermen og ikkje linja.

Registrer tida frå ende til ende for éi brukarhandling før du endrar noko. Det talet er den einaste referansen som kan fortelje deg om ei seinare retting verka.

Tel sekvensielle vendingar i éi brukarhandling

Instrumenter klienten i staden for å gjette. I psql skriv \timing on ut medgått tid for kvar setning, og EXPLAIN (ANALYZE, BUFFERS) viser kor mykje av den tida tenaren faktisk brukte på arbeidet.

Avstanden mellom desse to tala er nettverks- og klientkostnaden din. Viss ei setning køyrer på to millisekund og klienten registrerer seksti, er dei resterande femtiåtte reise og lokal handsaming, og ingen indeks fjernar dei. Gjenta samanlikninga for kvar setning skjermen sender, og summer avstandane i staden for utføringstidene.

Skriv ned resultatet som eit tal på sekvensielle vendingar. Det er mengda dei to neste avsnitta kan redusere, og det er eit tal du kan argumentere for med prov.

Samle dei uavhengige kalla, behald dei avhengige

To setningar som ikkje les resultatet til kvarandre kan reise saman og samlast inn éin gong, noko som gjer to vendingar til éi. To setningar der den andre treng verdien frå den første kan ikkje, fordi avhengnaden er reell og batching ville endre det programmet gjer. Sorter kalla i dei to haugane før du skriv om noko, og storleiken på kvar haug fortel deg kva som er mogleg.

Settbasert arbeid fjernar vendingar grundigare enn batching. Éi spørjing som returnerer radene ei løkke henta éin om gongen, fjernar løkka så vel som rundturane. Sjå etter løkka først, fordi ho vanlegvis er den største gevinsten og den enklaste endringa å gjennomgå.

Ein batch må framleis bevare feilhandtering og transaksjonsgrenser. Å setje saman urelaterte setningar til éin streng er ikkje ei trygg optimalisering, og ein batch som skjuler ei mislukka setning bak ei vellukka innsending er verre enn vendingane han sparte.

Bruk tilkoplingar om att før du kjøper bandbreidd

Ei ny tilkopling kostar namneoppslag, TCP-handtrykk, TLS-forhandling og autentisering, og på ein veg med høg forseinking er kvar av dei nok ein rundtur før den første spørjinga køyrer. Tilkoplingspoolar finst for å betale den kostnaden éin gong per prosess i staden for éin gong per kall.

I ADO.NET returnerer lukking eller dispose av ei poola tilkopling ho for gjenbruk i staden for å opne ei ny fysisk, så mønsteret som ser ut som ein lekkasje er ofte rett bruk. Stadfest at poolen faktisk er i bruk i staden for å anta det: logg oppretting av fysiske tilkoplingar, eller følg med på sesjonstalet på tenaren medan skjermen køyrer. SQL-ytingrettleiinga seier det same om å redusere rundturar og å batch-e hyppige ad hoc-kall, med tenestespesifikke døme du bør kople til di eiga utrulling.

Pooling fjernar oppsettkostnaden og lét dei serielle spørjeventingane vere urørte. Det er ein føresetnad for ei rein måling, ikkje ei retting i seg sjølv.

Vurder å flytte utføringa nærare dataa

Å køyre applikasjonen nær databasen erstattar mange eksterne databaseutvekslingar med éin ekstern visingssesjon. For ei pratsam arbeidslast kan det vere ei stor endring, og det er ei driftsendring like mykje som ei ytingsendring: sesjonsstyring, tilgangskontroll, programvaredistribusjon og brukaroppleving flyttar alle med applikasjonen.

Mål det faktiske grensesnittet og dataa det overfører før du antar at noka retning er raskare. Ein ekstern skrivebordssesjon flyttar pikslar, og ein skjerm med tett grafikk kan yte dårlegare over same veg enn spørjingane han erstatta, særleg når klienten teiknar på nytt kontinuerleg.

Gjenta så den opphavlege handlinga og samanlikn tre tal: sekvensielle vendingar, resultatvolum og fullføringstid frå ende til ende. Ei betring som endrar den målte brukaroppgåva medan ho bevarer datakorrektheit og tilgangspolitikk, er den som er verdt å behalde.