Proč se ukecaná SQL aplikace plazí přes VPN a co dávkovat

Formulář, který se v místní síti vykreslí za méně než sekundu, přes VPN trvá pět sekund, zatímco kopírování souboru na stejném spoji běží plnou rychlostí. Rozdíl není v šířce pásma. Formulář čeká na sled odpovědí a na každém kroku platí celý obrat, kdežto kopírování souboru drží bajty v pohybu nepřetržitě. Spočítejte tato čekání, než sáhnete na přístupovou linku.

Příznakem je obrazovka, ne dotaz

Každý dotaz na této obrazovce může být rychlý a obrazovka může být přesto pomalá, protože celek je součet čekání, nikoli součet dob provádění. Příkaz, který se provede za dvě milisekundy, pořád stojí celý obrat, když klient musí dostat jeho výsledek, než pošle další. Na cestě se čtyřiceti milisekundami zpoždění sto závislých volání nasčítá zhruba čtyři sekundy, než začne jakákoli práce na vykreslení. Tato aritmetika je model čekání, ne měření vašeho spoje.

Proto test rychlosti vypadá nevinně. Hromadný přenos měří propustnost, ukecaný formulář měří zpoždění a VPN může být v jednom vynikající a v druhém průměrná. Diagnostikovat obrazovku tedy znamená měřit obrazovku, ne spoj.

Před jakoukoli změnou zaznamenejte dobu jednoho uživatelského úkonu od začátku do konce. To číslo je jediná základní linie, která vám může říct, zda pozdější oprava zabrala.

Spočítejte po sobě jdoucí čekání v jednom uživatelském úkonu

Měřte v klientu, místo abyste hádali. V psql vypíše \timing on uplynulý čas každého příkazu a EXPLAIN (ANALYZE, BUFFERS) ukáže, kolik z toho času server skutečně strávil prací.

Mezera mezi těmito dvěma čísly je vaše síťová a klientská režie. Pokud se příkaz provede za dvě milisekundy a klient zaznamená šedesát, zbývajících padesát osm je cesta a místní zpracování a žádný index je neodstraní. Zopakujte toto srovnání pro každý příkaz, který obrazovka vydá, a sčítejte mezery, ne doby provádění.

Výsledek zapište jako počet po sobě jdoucích čekání. To je veličina, kterou mohou následující dvě části snížit, a je to číslo, o němž se dá hádat s důkazy.

Sdružte nezávislá volání, závislá ponechte

Dva příkazy, které navzájem nečtou své výsledky, mohou cestovat spolu a být sehrány jednou, což promění dvě čekání v jedno. Dva příkazy, kde druhý potřebuje hodnotu z prvního, to nemohou, protože závislost je skutečná a dávkování by změnilo, co program dělá. Před jakýmkoli přepisováním roztřiďte volání do těchto dvou hromádek a velikost každé hromádky vám řekne, co je možné.

Práce nad množinami odstraňuje čekání důkladněji než dávkování. Jeden dotaz, který vrací řádky, jež smyčka načítala jeden po druhém, odstraní i smyčku i obraty. Hledejte nejdřív smyčku, protože bývá větší zisk a snadnější změna pro revizi.

Dávka musí stále zachovat ošetření chyb a hranice transakcí. Spojování nesouvisejících příkazů do jednoho řetězce není bezpečná optimalizace a dávka, která schová neúspěšný příkaz za úspěšné odeslání, je horší než ušetřená čekání.

Znovu používejte spojení, než koupíte šířku pásma

Nové spojení stojí překlad jmen, TCP handshake, vyjednávání TLS a ověření, a na cestě s vysokým zpožděním je každé z toho dalším obratem, než se spustí první dotaz. Fondy spojení existují proto, aby se tato cena platila jednou na proces, ne jednou na volání.

V ADO.NET zavření nebo uvolnění spojení z fondu vrátí spojení k opětovnému použití místo otevření nového fyzického, takže vzor, který vypadá jako únik, je často správné použití. Ověřte, že se fond skutečně používá, místo abyste to předpokládali: logujte vytváření fyzických spojení nebo sledujte počet relací na serveru, dokud obrazovka běží. Pokyny k výkonu SQL říkají totéž o snižování obratů a dávkování častých ad hoc volání, s příklady pro konkrétní službu, které byste měli promítnout do svého nasazení.

Sdružování odstraňuje náklady na navázání a ponechává po sobě jdoucí čekání dotazů nedotčená. Je to předpoklad čistého měření, ne oprava sama o sobě.

Zvažte přesun provádění blíž k datům

Spouštění aplikace blízko databáze nahrazuje mnoho vzdálených výměn s databází jedinou vzdálenou zobrazovací relací. Pro ukecanou zátěž to může být velká změna a je to provozní změna stejně jako změna výkonu: správa relací, řízení přístupu, nasazování softwaru i uživatelský zážitek se stěhují spolu s aplikací.

Změřte skutečné rozhraní a data, která přenáší, než budete předpokládat, že je některý směr rychlejší. Vzdálená relace pracovní plochy přenáší pixely a obrazovka s hustou grafikou může na stejné cestě dopadnout hůř než dotazy, které nahradila, zvlášť když klient nepřetržitě překresluje.

Potom zopakujte původní úkon a porovnejte tři čísla: po sobě jdoucí čekání, objem výsledků a dobu dokončení od začátku do konce. Zlepšení, které změní měřený uživatelský úkol a přitom zachová správnost dat a přístupovou politiku, je to, které stojí za to ponechat.