Kāpēc runīga SQL lietotne VPN tīklā velkas un ko vērts apvienot paketēs

Veidlapa, kas vietējā tīklā atveras mazāk nekā sekundē, VPN tīklā aizņem piecas sekundes, bet faila kopija tajā pašā līnijā iet ar pilnu ātrumu. Atšķirība nav joslas platums. Veidlapa gaida atbilžu virkni un katrā solī maksā pilnu apļveida ceļu, bet faila kopija nepārtraukti tur baitus ceļā. Saskaitiet šīs gaidīšanas, pirms ķeraties pie piekļuves līnijas.

Simptoms ir ekrāns, nevis vaicājums

Katrs vaicājums šajā ekrānā var būt ātrs, un ekrāns tomēr var būt lēns, jo kopsumma ir gaidīšanu summa, nevis izpildes laiku summa. Paziņojums, kas izpildās divās milisekundēs, tomēr maksā visu apļveida ceļu, ja klientam jāsaņem tā rezultāts pirms nākamā nosūtīšanas. Ceļā ar četrdesmit milisekundžu latentumu simts atkarīgu izsaukumu sakrājas aptuveni četrās sekundēs, pirms sākas jebkāds renderēšanas darbs. Šī aritmētika ir gaidīšanas modelis, nevis jūsu līnijas etalons.

Tāpēc ātruma tests izskatās nevainīgs. Lielapjoma pārsūtīšana mēra caurlaidību, runīga veidlapa mēra latentumu, un VPN var būt izcils vienā un palikt parasts otrā. Tāpēc ekrāna diagnostika nozīmē ekrāna, nevis līnijas mērīšanu.

Pirms kaut ko mainīt, pierakstiet vienas lietotāja darbības laiku no sākuma līdz beigām. Tikai šis skaitlis var pateikt, vai vēlāks labojums ir nostrādājis.

Saskaitiet secīgās gaidīšanas vienā lietotāja darbībā

Tā vietā, lai minētu, instrumentējiet klientu. psql \timing on izdrukā katra paziņojuma pagājušo laiku, un EXPLAIN (ANALYZE, BUFFERS) parāda, cik daudz no šī laika serveris patiešām pavadīja darbā.

Starpība starp šiem diviem skaitļiem ir jūsu tīkla un klienta izmaksas. Ja paziņojums izpildās divās milisekundēs, bet klients fiksē sešdesmit, atlikušās piecdesmit astoņas ir ceļš un vietējā apstrāde, un neviens indekss tās nenoņems. Atkārtojiet šo salīdzinājumu katram ekrāna izdotajam paziņojumam un summējiet starpības, nevis izpildes laikus.

Pierakstiet rezultātu kā secīgo gaidīšanu skaitu. Tieši šo lielumu var samazināt nākamās divas sadaļas, un tas ir skaitlis, par ko var strīdēties ar pierādījumiem.

Apvienojiet neatkarīgos izsaukumus, atstājiet atkarīgos

Divi paziņojumi, kas nelasa viens otra rezultātus, var ceļot kopā un tikt savākti vienreiz, kas divas gaidīšanas pārvērš vienā. Divi paziņojumi, kur otrajam vajag pirmā vērtību, to nevar, jo atkarība ir reāla un apvienošana mainītu to, ko programma dara. Pirms kaut ko pārrakstīt, sakārtojiet izsaukumus divos kaudzēs, un katras kaudzes lielums pasaka, kas ir iespējams.

Kopu darbs gaidīšanas novērš pamatīgāk nekā apvienošana. Viens vaicājums, kas atgriež rindas, ko cilpa ņēma pa vienai, novērš gan cilpu, gan apļveida ceļus. Vispirms meklējiet cilpu, jo tā parasti ir lielākais ieguvums un vieglāk pārskatāmas izmaiņas.

Apvienošanai joprojām jāsaglabā kļūdu apstrāde un transakciju robežas. Nesaistītu paziņojumu savienošana vienā virknē nav droša optimizācija, un apvienojums, kas neizdevušos paziņojumu paslēpj aiz veiksmīgas iesniegšanas, ir sliktāks par ietaupītajām gaidīšanām.

Izmantojiet savienojumus atkārtoti, pirms pērkat joslas platumu

Jauns savienojums maksā vārdu atrisināšanu, TCP rokasspiedienu, TLS sarunas un autentifikāciju, un liela latentuma ceļā katrs no tiem ir vēl viens apļveida ceļš pirms pirmā vaicājuma. Savienojumu pūli pastāv, lai šīs izmaksas segtu vienreiz uz procesu, nevis vienreiz uz izsaukumu.

ADO.NET pūla savienojuma aizvēršana vai dispose atgriež to atkārtotai lietošanai, nevis atver jaunu fizisku savienojumu, tāpēc modelis, kas izskatās pēc noplūdes, bieži ir pareizā lietošana. Pārbaudiet, vai pūls tiešām tiek lietots, nevis pieņemiet to: reģistrējiet fizisku savienojumu izveidi vai vērojiet sesiju skaitu serverī, kamēr ekrāns darbojas. SQL veiktspējas norādnes saka to pašu par apļveida ceļu samazināšanu un biežu ad hoc izsaukumu apvienošanu, ar pakalpojumam raksturīgiem piemēriem, kas jāpielāgo jūsu izvietojumam.

Pūlošana novērš iestatīšanas izmaksas un atstāj secīgās vaicājumu gaidīšanas neskartas. Tā ir priekšnoteikums tīram mērījumam, nevis labojums pats par sevi.

Izsvērt izpildes pārvietošanu tuvāk datiem

Lietotnes darbināšana blakus datubāzei daudzas attālinātas datubāzes apmaiņas aizstāj ar vienu attālinātu displeja sesiju. Runīgai slodzei tas var būt liels lēmums, un tās ir gan operatīvas, gan veiktspējas izmaiņas: sesiju pārvaldība, piekļuves kontrole, programmatūras izvietošana un lietotāja pieredze visi pārvietojas kopā ar lietotni.

Izmēriet faktisko saskarni un datus, ko tā pārsūta, pirms pieņemat, ka kāds virziens ir ātrāks. Attālinātā darbvirsmas sesija pārvieto pikseļus, un ekrāns ar blīvu grafiku tajā pašā ceļā var darboties sliktāk nekā vaicājumi, ko tas aizstāja, jo īpaši, ja klients nepārtraukti pārzīmē.

Pēc tam atkārtojiet sākotnējo darbību un salīdziniet trīs skaitļus: secīgās gaidīšanas, rezultāta apjomu un pabeigšanas laiku no sākuma līdz beigām. Uzlabojums, kas maina izmērīto lietotāja uzdevumu, saglabājot datu pareizību un piekļuves politiku, ir tas, ko vērts paturēt.