Miért vánszorog egy beszédes SQL-alkalmazás VPN-en, és mit érdemes kötegelni

Egy űrlap, amely helyi hálózaton egy másodperc alatt megjelenik, VPN-en át öt másodpercet vesz igénybe, miközben egy fájlmásolás ugyanazon a kapcsolaton teljes sebességgel fut. A különbség nem a sávszélesség. Az űrlap válaszok sorozatára vár, és minden lépésnél megfizeti a teljes oda-vissza utat, míg a fájlmásolás folyamatosan mozgásban tartja a bájtokat. Számolja meg ezeket a várakozásokat, mielőtt hozzányúlna a hozzáférési vonalhoz.

A tünet egy képernyő, nem egy lekérdezés

A képernyő minden lekérdezése lehet gyors, és a képernyő mégis lassú lehet, mert az összeg a várakozások összege, nem a végrehajtási idők összege. Egy két ezredmásodperc alatt lefutó utasítás is teljes oda-vissza utat ér, amikor az ügyfélnek meg kell kapnia az eredményét, mielőtt a következőt elküldi. Egy negyven ezredmásodperces késleltetésű útvonalon száz függő hívás körülbelül négy másodpercre gyűlik, mielőtt bármilyen rajzolási munka elkezdődne. Ez az aritmetika a várakozás modellje, nem a kapcsolat mérése.

Ezért tűnik ártatlannak egy sebességteszt. A tömeges átvitel az átbocsátást méri, egy beszédes űrlap a késleltetést, és egy VPN lehet kiváló az egyikben, miközben átlagos marad a másikban. A képernyő diagnosztizálása tehát a képernyő mérését jelenti, nem a kapcsolatét.

Rögzítse egyetlen felhasználói művelet végponttól végpontig tartó idejét, mielőtt bármit megváltoztat. Ez a szám az egyetlen alapvonal, amely meg tudja mondani, hogy egy későbbi javítás működött-e.

Számolja meg a sorrendi várakozásokat egyetlen felhasználói műveletben

Az ügyfélben mérjen, ne találgasson. A psql-ben a \timing on kiírja az egyes utasítások eltelt idejét, a EXPLAIN (ANALYZE, BUFFERS) pedig megmutatja, hogy abból az időből mennyit töltött a kiszolgáló ténylegesen a munkával.

A két szám közötti különbség a hálózati és ügyféloldali többletköltség. Ha egy utasítás két ezredmásodperc alatt fut le, és az ügyfél hatvanat jegyez, a fennmaradó ötvennyolc utazás és helyi feldolgozás, és egyetlen index sem távolítja el őket. Ismételje meg ezt az összehasonlítást minden utasításra, amelyet a képernyő kiad, és a különbségeket adja össze, ne a végrehajtási időket.

Írja le az eredményt a sorrendi várakozások számaként. Ez az a mennyiség, amelyet a következő két szakasz csökkenthet, és ez olyan szám, amelyről bizonyítékokkal lehet vitatkozni.

Kötegelje a független hívásokat, tartsa meg a függőket

Két utasítás, amelyek nem olvassák egymás eredményét, együtt utazhat és egyszer gyűjthető be, ami két várakozást eggyé tesz. Két utasítás, ahol a másodiknak az első értékére van szüksége, ezt nem teheti, mert a függőség valós, és a kötegelés megváltoztatná, mit tesz a program. Rendezze a hívásokat ebbe a két kupacba, mielőtt bármit átír, és az egyes kupacok mérete megmondja, mi lehetséges.

A halmazalapú munka alaposabban távolítja el a várakozásokat, mint a kötegelés. Egy lekérdezés, amely visszaadja azokat a sorokat, amelyeket egy ciklus egyenként hozott, megszünteti a ciklust és az oda-vissza utakat is. Először a ciklust keresse, mert általában az a nagyobb nyereség és a könnyebben átnézhető változtatás.

Egy kötegnek továbbra is meg kell őriznie a hibakezelést és a tranzakcióhatárokat. Összefüggéstelen utasítások egyetlen karakterláncba fűzése nem biztonságos optimalizálás, és az a köteg, amely egy sikertelen utasítást sikeres beküldés mögé rejt, rosszabb a megtakarított várakozásoknál.

Használja újra a kapcsolatokat, mielőtt sávszélességet vásárol

Egy új kapcsolat névfeloldást, TCP-kézfogást, TLS-tárgyalást és hitelesítést igényel, és nagy késleltetésű útvonalon ezek mindegyike még egy oda-vissza út, mielőtt az első lekérdezés elindul. A kapcsolatkészletek azért léteznek, hogy ezt a költséget folyamatonként egyszer fizessük meg, ne hívásonként egyszer.

Az ADO.NET-ben egy készletezett kapcsolat bezárása vagy eldobása újrafelhasználásra adja vissza, nem új fizikai kapcsolatot nyit, ezért a szivárgásnak látszó minta gyakran a helyes használat. Ellenőrizze, hogy a készletet valóban használják-e, ne feltételezze: naplózza a fizikai kapcsolatok létrehozását, vagy figyelje a munkamenetek számát a kiszolgálón, miközben a képernyő fut. Az SQL teljesítményre vonatkozó útmutatás ugyanezt mondja az oda-vissza utak csökkentéséről és a gyakori ad hoc hívások kötegeléséről, szolgáltatásspecifikus példákkal, amelyeket a saját telepítésére kell leképeznie.

A készletezés megszünteti a beállítási költséget, és érintetlenül hagyja a sorrendi lekérdezési várakozásokat. Előfeltétele a tiszta mérésnek, nem önmagában javítás.

Mérlegelje a végrehajtás közelebb vitelét az adatokhoz

Az alkalmazás adatbázis közelében futtatása sok távoli adatbázis-cserét vált ki egyetlen távoli megjelenítési munkamenetre. Egy beszédes terhelésnél ez nagy változás lehet, és ez üzemeltetési változás éppúgy, mint teljesítményváltozás: a munkamenet-kezelés, a hozzáférés-vezérlés, a szoftvertelepítés és a felhasználói élmény mind együtt mozog az alkalmazással.

Mérje meg a tényleges felületet és az általa átvitt adatokat, mielőtt feltételezné, hogy bármelyik irány gyorsabb. Egy távoli asztali munkamenet pixeleket mozgat, és egy sűrű grafikájú képernyő ugyanazon az útvonalon rosszabbul teljesíthet, mint a helyére lépett lekérdezések, különösen amikor az ügyfél folyamatosan újrarajzol.

Ezután ismételje meg az eredeti műveletet, és hasonlítson össze három számot: sorrendi várakozások, eredmény mennyisége és végponttól végpontig tartó befejezési idő. Az a javítás érdemes megtartásra, amely megváltoztatja a mért felhasználói feladatot, miközben megőrzi az adatok helyességét és a hozzáférési szabályzatot.