Kodėl kalbi SQL programa lėtai veikia per VPN ir ką reikia grupuoti

Forma, kuri vietiniame tinkle atsidaro per mažiau nei sekundę, per VPN užtrunka penkias sekundes, o failo kopija ta pačia linija eina visu greičiu. Skirtumas ne pralaidumas. Forma laukia atsakymų sekos ir kiekviename žingsnyje sumoka visą kelionę pirmyn ir atgal, o failo kopija nuolat laiko baitus kelyje. Suskaičiuokite tuos laukimus prieš liedami prieigos liniją.

Simptomas yra ekranas, o ne užklausa

Kiekviena to ekrano užklausa gali būti greita, o ekranas vis tiek gali būti lėtas, nes visuma yra laukimų suma, o ne vykdymo laikų suma. Sakinys, vykdomas per dvi milisekundes, vis tiek kainuoja visą kelionę, kai klientas turi gauti rezultatą prieš siųsdamas kitą. Kelyje, kurio delsa keturiasdešimt milisekundžių, šimtas priklausomų kvietimų susikaupia maždaug keturias sekundes, kol dar neprasidėjo joks atvaizdavimo darbas. Ši aritmetika yra laukimo modelis, o ne jūsų linijos matavimas.

Štai kodėl greičio testas atrodo nekaltas. Didelis perdavimas matuoja pralaidumą, kalbi forma matuoja delsą, o VPN gali būti puikus viename ir likti paprastas kitame. Todėl diagnozuoti ekraną reiškia matuoti ekraną, o ne liniją.

Prieš ką nors keisdami užrašykite vieno vartotojo veiksmo laiką nuo pradžios iki pabaigos. Tik šis skaičius gali pasakyti, ar vėlesnis pataisymas suveikė.

Suskaičiuokite nuoseklius laukimus viename vartotojo veiksme

Užuot spėlioję, instrumentuokite klientą. psql \timing on atspausdina kiekvieno sakinio praėjusį laiką, o EXPLAIN (ANALYZE, BUFFERS) parodo, kiek to laiko serveris iš tikrųjų skyrė darbui.

Skirtumas tarp šių dviejų skaičių yra jūsų tinklo ir kliento sąnaudos. Jei sakinys įvykdomas per dvi milisekundes, o klientas užfiksuoja šešiasdešimt, likę penkiasdešimt aštuoni yra kelionė ir vietinis apdorojimas, ir joks indeksas jų nepašalins. Kartokite šį palyginimą kiekvienam ekrano siunčiamam sakiniui ir sumuokite skirtumus, o ne vykdymo laikus.

Užrašykite rezultatą kaip nuoseklių laukimų skaičių. Būtent šį dydį gali sumažinti kiti du skyriai, ir tai yra skaičius, dėl kurio galima ginčytis su įrodymais.

Sugrupuokite nepriklausomus kvietimus, palikite priklausomus

Du sakiniai, kurie neskaito vienas kito rezultatų, gali keliauti kartu ir būti surinkti vieną kartą, o tai du laukimus paverčia vienu. Du sakiniai, kur antrasis reikia pirmojo reikšmės, to negali, nes priklausomybė tikra, o grupavimas pakeistų tai, ką programa daro. Prieš ką nors perrašydami surūšiuokite kvietimus į tas dvi krūvas, o kiekvienos krūvos dydis pasakys, kas įmanoma.

Rinkiniu pagrįstas darbas pašalina laukimus kruopščiau nei grupavimas. Viena užklausa, grąžinanti eilutes, kurias ciklas ėmė po vieną, pašalina ir ciklą, ir keliones. Pirmiausia ieškokite ciklo, nes jis paprastai duoda didesnę naudą ir yra lengviau peržiūrimas pakeitimas.

Grupuojant vis tiek reikia išsaugoti klaidų apdorojimą ir transakcijų ribas. Nesusijusių sakinių sujungimas į vieną eilutę nėra saugi optimizacija, o grupė, kuri nepavykusį sakinį paslepia už sėkmingo pateikimo, yra blogesnė už sutaupytus laukimus.

Naudokite jungtis iš naujo, prieš pirkdami pralaidumą

Nauja jungtis kainuoja vardo išsprendimą, TCP rankos paspaudimą, TLS derybas ir autentifikavimą, o didelės delsos kelyje kiekvienas jų yra dar viena kelionė prieš pirmą užklausą. Jungčių telkiniai egzistuoja, kad šias sąnaudas sumokėtumėte kartą per procesą, o ne kartą per kvietimą.

ADO.NET telkino jungties uždarymas ar dispose grąžina ją naudoti iš naujo, o ne atidaro naują fizinę jungtį, todėl modelis, kuris atrodo kaip nutekėjimas, dažnai yra teisingas naudojimas. Patikrinkite, ar telkinys tikrai naudojamas, o ne manykite: registruokite fizinių jungčių kūrimą arba stebėkite sesijų skaičių serveryje, kol ekranas veikia. SQL našumo rekomendacijos sako tą patį apie kelionių mažinimą ir dažnų ad hoc kvietimų grupavimą, su paslaugai būdingais pavyzdžiais, kuriuos turėtumėte pritaikyti savo diegimui.

Telkimas pašalina sąrankos sąnaudas ir palieka nuoseklius užklausų laukimus nepaliestus. Tai būtina sąlyga švariam matavimui, o ne savarankiškas pataisymas.

Apsvarstykite vykdymo perkėlimą arčiau duomenų

Programos vykdymas prie duomenų bazės daugelį nuotolinių duomenų bazės mainų pakeičia viena nuotoline ekrano sesija. Kalbiam darbo krūviui tai gali būti didelis pokytis, ir tai yra tiek veiklos, tiek našumo pokytis: sesijų valdymas, prieigos kontrolė, programinės įrangos diegimas ir vartotojo patirtis juda kartu su programa.

Prieš manydami, kad kuri nors kryptis greitesnė, išmatuokite tikrąją sąsają ir duomenis, kuriuos ji perduoda. Nuotolinio darbalaukio sesija perkelia pikselius, o ekranas su tankia grafika tame pačiame kelyje gali veikti prasčiau nei užklausos, kurias jis pakeitė, ypač kai klientas nuolat perpiešia.

Tada pakartokite pradinį veiksmą ir palyginkite tris skaičius: nuoseklius laukimus, rezultato apimtį ir užbaigimo laiką nuo pradžios iki pabaigos. Tobulinimas, kuris pakeičia matuojamą vartotojo užduotį, išsaugant duomenų teisingumą ir prieigos politiką, yra tas, kurį verta palikti.