Architektury split-stack jsou stejně prominentní jako kdykoli předtím. Spotřebitelé využívají nasazení v multicloudu a rozlehlých sítích (WAN), aby získali nejlepší služby ve své třídě na každé úrovni, zůstali bez cloudu, snížili náklady a chránili před katastrofou. Zatímco mnoho síťových pokroků učinilo taková nastavení realitou, latenci lze stále zavádět mnoha způsoby.
Latence může být zvláště škodlivá mezi aplikací a databází. Naštěstí s databází Oracle existuje několik způsobů, jak vyladit síťové parametry pro optimalizaci výkonu přes připojení s vysokou latencí.
Co je velikost načtení?
Velikost načtení je počet řádků načtených za síťové volání. Ve výchozím nastavení používá většina ovladačů Java Database Connectivity (JDBC) velikost načtení 10. Pokud čtete 1 000 objektů, je k získání dat zapotřebí 100 síťových volání. Zvýšení velikosti načtení na 250 má za následek pouze 4 síťová volání. V sítích s nízkou latencí je tento rozdíl zanedbatelný, ale je triviální vidět, jaký dopad může mít toto měřítko v síti s vysokou latencí.
Proč nechcete, aby byla velikost načtení co největší? Jak zvětšujete velikost načítání, klientská aplikace používá více paměti k uložení všech řádků vrácených jedním načtením. Velikost načítání není jedna velikost pro všechny, ale něco, co je třeba před nasazením vyladit a otestovat
Linux Traffic Control
Jedním ze způsobů, jak zavést latenci sítě, je příkaz Linux Traffic Control (TC). Příkaz TC pomáhá při kontrole, klasifikaci, tvarování a plánování síťového provozu. Můžeme jej použít k přidání zpoždění s každým síťovým paketem. Podívejme se na to v akci.
Obrázek 1: Normální ping
Bez síťového zpoždění je průměrná doba, kterou trvá ping na databázi, asi 0,2 ms. Přidejme zpoždění 5 ms pomocí TC.
Obrázek 2: Ping se zpožděním 5 ms
Obrázek 2 ukazuje průměrný čas 5,2 ms, jak se očekávalo.
Testování
Proveďte dva testy pro následující informace:
- Monitorujte dopad různé latence a velikosti načítání pro datové sklady a úlohy OLTP
- Zjistěte, zda Linux TC je dobrou reprezentací skutečné latence
Pro pracovní zátěž používám jednoduchý nástroj Python od našeho týmu pro výkon v reálném světě, který generuje data za chodu a měří latenci sítě mezi klientem a databází Oracle. Tento nástroj má režimy datového skladu i OLTP, což v podstatě určuje, jak analytický/intenzivní je SQL, a snadno mi umožňuje měnit velikost načítání.
Test 1: Měnící se latence a velikost načítání
Založit
Nastavení je jednoduché, klient a databáze jsou ve stejné podsíti a doméně dostupnosti Oracle Cloud Infrastructure (OCI), což má latenci 0,2 ms. Přidávám latenci 5, 10 a 15 ms pomocí TC a měním velikost načítání na 20, 100, 250 a 500 pro každý.
Obrázek 3: Nastavení testu 1
Analýza času klienta
Obrázek 4: Graf času klienta versus latence
Obrázek 5: Graf času klienta versus velikost načtení
Tyto grafy analyzují celkový čas potřebný ke spuštění testovacích dotazů, jak je vidí klient. Čas strávený na klientovi se zvyšuje téměř lineárně jak u datového skladu, tak u zátěže OLTP se zvyšující se latencí. Velikost načtení má velký dopad na zátěž datového skladu, ale téměř žádný vliv na zátěž OLTP. Zvýšení velikosti načítání zkracuje čas klienta, ale zdánlivě jen do určité hranice. Na obrázku 5 se čas klienta začíná vyrovnávat kolem velikosti načtení 250.
Analýza času sítě
Obrázek 6: Graf sítě čas versus latence
Obrázek 7: Graf sítě čas versus velikost načtení
Tyto grafy analyzují celkový čas strávený v síti po dobu trvání testu a vypadají velmi podobně jako časové grafy klienta. Tento výsledek naznačuje, že čas sítě je hnacím faktorem našeho testu. Podívejme se, zda můžeme tuto hypotézu potvrdit, když se podíváme na procento celkového času stráveného v síti.
Analýza procent času stráveného v síti
Obrázek 8: Graf procenta času sítě versus latence
Obrázek 9: Graf procenta času sítě versus velikost načtení
Procento času sítě se vypočítá jako čas sítě dělený časem klienta. Zvyšuje se se zvýšenou latencí. Bez vyladění velikosti načtení zabírá čas sítě velké procento celkového času zátěže datového skladu. Správně vyladěná velikost aportu však tento poměr výrazně zlepšuje.
Doba zpracování SQL
Můžete být znepokojeni tím, jak velké je procento síťového času. I když síť má významný dopad, je také důležité plně porozumět tomuto poměru. Čas klienta se rovná času v síti + času v databázi. Můžeme tedy přepsat náš poměr jako následující rovnici:
% času sítě = čas sítě ⁄ (čas sítě + čas databáze)
Skutečně měříme síťový čas ve srovnání s časem databáze. Pokud je tedy čas naší databáze malý, tento poměr se zvyšuje. Každý z našich běhů SQL trval následující časy:
- Průměrný s/SQL pro DWH: 0,18582
- Průměrný s/SQL pro OLTP: 0,00026
Obě tyto délky jsou rychlé, přičemž OLTP je extrémně rychlý. U zátěží v reálném světě, zejména dotazů na datové sklady s delšími procesy SQL, se tento poměr snižuje. Je důležité porozumět tomu, do kterého úzkého místa, sítě nebo databáze, vaše aplikace naráží!
Test 2: Linux TC versus reálná latence
Založit
Co se týče latence v reálném světě, klient a databáze jsou v různých oblastech s průměrnou latencí 76,2 ms. Simulovaná latence má klienta a databázi ve stejné oblasti a doméně dostupnosti a my používáme příkaz TC k simulaci 76,2 ms latence.
Obrázek 10: Nastavení testu 2
Výsledek
Obrázek 11: Výsledky testu 2
Analýza
Výsledky při použití Linux TC a skutečné latence jsou téměř totožné pro oba typy zátěže. Můžeme s jistotou dojít k závěru, že Linux TC je účinnou simulací reálné latence pro datové sklady i zátěže OLTP, což z ní činí cenný nástroj pro testování dopadu latence na zátěž. Opět dostáváme výhody velikosti načítání pro pracovní zátěž datového skladu a zanedbatelný efekt pro OLTP.
Závěr
Architektury Split-stack a WAN mají mnoho výhod, ale mohou také zavádět latenci, protože zdroje jsou rozmístěny dále od sebe. Testování, ladění a optimalizace síťových parametrů je v takovém nastavení nejdůležitější. Jedním takovým parametrem, který je třeba prozkoumat, je velikost načtení, což je počet řádků načtených na síťové volání. V tomto blogu jsme použili Linux Traffic Control (TC) k simulaci síťové latence a různé velikosti načítání pro datový sklad a zátěž OLTP. Viděli jsme, jak významný dopad může mít latence na aplikaci, zjistili jsme, že velikost načítání má hluboký vliv na datový sklad, ale ne na pracovní zátěž typu OLTP, a že existuje limit, po jehož překročení má rostoucí velikost načítání klesající návratnost času klienta. Také jsme potvrdili, že Linux TC je dostatečnou reprezentací reálné latence pro datové sklady i pracovní zátěže OLTP.
Každá aplikace a architektura jsou jiné. To znamená, že hodnoty parametrů nejsou univerzální, ale spíše jedinečné pro nasazení. V tomto blogu jsme se zaměřili na velikost načtení, ale toto je pouze jeden parametr, který je třeba analyzovat. Doporučuji vám využít příkaz Linux TC k simulaci latence a úplnému vyladění vaší aplikace!
Zdroj: Oracle
