Správa zatížení serveru pro službu Azure Cache for Redis
Velikosti hodnot
Návrh klientské aplikace určuje, jestli se má ukládat mnoho malých hodnot, nebo menší počet větších hodnot. Z pohledu serveru Redis menší hodnoty poskytují lepší výkon. Doporučujeme držet velikost hodnot menší než 100 kB.
Pokud návrh vyžaduje, abyste do služby Azure Cache for Redis ukládali větší hodnoty, zatížení serveru bude vyšší. V takovém případě možná budete muset použít vyšší úroveň mezipaměti, abyste zajistili, že využití procesoru neomezuje propustnost.
I když má mezipaměť dostatečnou kapacitu procesoru, větší hodnoty zvyšují latenci, proto postupujte podle pokynů v části Konfigurace vhodných časových limitů.
Větší hodnoty také zvyšují pravděpodobnost fragmentace paměti, proto postupujte podle pokynů v části Konfigurace nastavení maxmemory-reserved.
Zabránění špičkám připojení klientů
Vytváření a ukončování připojení je pro server Redis náročná operace. Pokud klientská aplikace vytvoří nebo ukončí příliš mnoho připojení během krátkého času, může to zatížit server Redis.
Pokud vytváříte mnoho instancí klientů pro připojení k Redisu najednou, zvažte rozložení vytváření nových připojení, abyste se vyhnuli prudkému nárůstu počtu připojených klientů.
Přetížení paměti
Vysoké využití paměti na serveru způsobuje větší pravděpodobnost, že systém potřebuje stránkovat data na disk, což vede k chybám stránkování, které můžou výrazně zpomalit systém.
Vyhýbání se dlouhotrvajícím příkazům
Server Redis je jednovláknový systém. Dlouhotrvající příkazy můžou způsobit latenci nebo vypršení časových limitů na straně klienta, protože server nemůže reagovat na žádné jiné požadavky, zatímco je zaneprázdněný prací na dlouho běžícím příkazu. Další informace najdete v tématu Řešení potíží Azure Cache for Redis na straně serveru.
Monitorování zatížení serveru
Přidejte monitorování zatížení serveru, abyste měli jistotu, že budete dostávat oznámení, když k vysokému zatížení serveru dojde. Monitorování vám může pomoct pochopit omezení vaší aplikace. Pak můžete aktivně pracovat na zmírnění problémů. Doporučujeme snažit se udržet zatížení serveru pod 80 %, abyste se vyhnuli negativním dopadům na výkon. Trvalé zatížení serveru přes 80 % může vést k neplánovaným převzetí služeb při selhání. Azure Cache for Redis v současné době zveřejňuje dvě metriky v Přehledy v části Monitorování v nabídce Prostředky na levé straně portálu: Procesor a zatížení serveru. Při monitorování zatížení serveru je důležité porozumět tomu, co jednotlivé metriky měří.
Metrika procesoru označuje využití procesoru pro uzel, který je hostitelem mezipaměti. Metrika Procesor také zahrnuje procesy, které nejsou výhradně procesy serveru Redis. Metrika Procesor zahrnuje procesy na pozadí pro antimalwarovou ochranu a další. V důsledku toho může metrika Procesor někdy narůst a nemusí být dokonalým indikátorem využití procesoru pro server Redis.
Metrika Zatížení serveru představuje zatížení samotného Serveru Redis. Místo procesoru doporučujeme monitorovat metriku zatížení serveru.
Při monitorování zatížení serveru také doporučujeme, abyste prozkoumali maximální špičky zatížení serveru, a ne průměr, protože i krátké špičky můžou aktivovat převzetí služeb při selhání a vypršení časových limitů příkazů.
Plánování údržby serveru
Ujistěte se, že máte dostatečnou kapacitu serveru pro zpracování zatížení ve špičce, zatímco servery mezipaměti procházejí údržbou. Otestujte systém restartováním uzlů během špičky. Další informace o tom, jak simulovat nasazení opravy, najdete v tématu restartování.
Testování zvýšeného zatížení serveru po převzetí služeb při selhání
U skladových položek úrovně Standard a Premium je každá mezipaměť hostovaná na dvou uzlech. Nástroj pro vyrovnávání zatížení distribuuje připojení klientů mezi dva uzly. Pokud na primárním uzlu dojde k plánované nebo neplánované údržbě, uzel ukončí všechna připojení klientů. V takových situacích můžou všechna připojení klientů směřovat na jeden uzel, což způsobí zvýšení zatížení serveru na tomto zbývajícím uzlu. Doporučujeme tento scénář otestovat restartováním primárního uzlu a zajištěním, aby jeden uzel zvládl všechna klientská připojení, aniž by zatížení serveru bylo příliš vysoké.