Nejčastější dotazy ke správě Azure Managed Redis (Preview)

Použití protokolu TLS se doporučuje jako osvědčený postup ve všech případech použití Redis. Možnost připojení bez protokolu TLS je zahrnuta pro účely zpětné kompatibility.

• Osvědčené postupy pro StackExchange.Redis
• Konfigurace a koncepty
• Testování výkonu

Osvědčené postupy pro StackExchange.Redis

• Nastavte AbortConnect hodnotu false a pak nechte connectionMultiplexer znovu připojit automaticky.
• Místo vytvoření nového připojení pro každou žádost použijte jednu dlouhou ConnectionMultiplexer instanci.
• Redis funguje nejlépe s menšími hodnotami, proto zvažte rozsekání větších dat do více klíčů. V diskuzi Redis je 100 kb považováno za velké. Další informace najdete v tématu Vývoj osvědčených postupů.
• Nakonfigurujte nastavení Fondu vláken, abyste se vyhnuli vypršení časových limitů.
• Použijte aspoň výchozí hodnotu connectTimeout 5 sekund. Tento interval dává StackExchange.Redis dostatek času k opětovnému navázání připojení, pokud existuje tečka sítě.
• Mějte na paměti náklady na výkon související s různými operacemi, které provozujete. Příkaz je například KEYS operace O(n), která by se měla vyhnout. Web redis.io obsahuje podrobnosti o časovém složitosti jednotlivých operací, které podporuje. Výběrem jednotlivých příkazů zobrazíte složitost jednotlivých operací.

Konfigurace a koncepty

• Mějte na paměti, že Redis je úložiště dat v paměti . Další informace najdete v tématu Řešení potíží se ztrátou dat ve službě Azure Managed Redis , abyste věděli o scénářích, ve kterých může dojít ke ztrátě dat.
• Vyvíjejte systém tak, aby mohl zpracovávat tři tečky připojení způsobené opravami a převzetím služeb při selhání.

Testování výkonu

• Podívejte se na testování výkonu pomocí Azure Managed Redis , například srovnávací testy a pokyny pro spouštění vlastních testů výkonnosti ve službě Azure Managed Redis.

• Vyhněte se používání určitých příkazů Redis, které trvá dlouhou dobu, pokud plně nerozumíte výsledku těchto příkazů. Například nespouštět příkaz KLÍČE v produkčním prostředí. V závislosti na počtu klíčů může vrácení trvat dlouhou dobu. Každý horizontální oddíl Redis je jednovláknový a zpracovává příkazy po jednom. Pokud máte po klíčích vydané další příkazy, nebudou zpracovány, dokud Redis nezpracuje příkaz KEYS. Web redis.io obsahuje podrobnosti o časovém složitosti jednotlivých operací, které podporuje. Výběrem jednotlivých příkazů zobrazíte složitost jednotlivých operací.
• Velikosti klíčů – mám použít malý klíč/hodnoty nebo velké klíče/hodnoty? Závisí na scénáři. Pokud váš scénář vyžaduje větší klíče, můžete upravit connectionTimeout, pak opakovat hodnoty a upravit logiku opakování. Z pohledu serveru Redis menší hodnoty poskytují lepší výkon.
• Tyto aspekty neznamená, že nemůžete ukládat větší hodnoty v Redisu; musíte vědět o následujících aspektech. Latence jsou vyšší. Pokud máte jednu sadu dat, která jsou větší a menší, můžete použít více instancí ConnectionMultiplexer. Nakonfigurujte každou z nich s jinou sadou časových limitů a hodnot opakování, jak je popsáno v předchozí části Možnosti konfigurace StackExchange.Redis.

• Povolte diagnostiku mezipaměti, abyste mohli monitorovat stav svojí mezipaměti. Metriky lze zobrazit na webu Azure Portal a můžete je také stáhnout a revidovat pomocí nástrojů dle vašeho výběru.
• Podívejte se na testování výkonu pomocí Azure Managed Redis , například srovnávací testy a pokyny pro spouštění vlastních testů výkonnosti ve službě Azure Managed Redis.

Fond vláken CLR má dva typy vláken – "Pracovní" a "Vstupně-výstupní port dokončení" (IOCP).

• Pracovní vlákna se používají pro věci, jako je zpracování Task.Run(…)nebo ThreadPool.QueueUserWorkItem(…) metody. Tato vlákna jsou také používána různými komponentami modulu CLR, pokud je potřeba pracovat na vlákně na pozadí.
• Vlákna IOCP se používají při asynchronním vstupně-výstupním operacím, například při čtení ze sítě.

Fond vláken poskytuje nová pracovní vlákna nebo vlákna dokončení vstupně-výstupních operací na vyžádání (bez omezení), dokud nedosáhne nastavení Minimum pro každý typ vlákna. Ve výchozím nastavení je minimální počet vláken nastaven na počet procesorů v systému.

Jakmile počet existujících (zaneprázdněných) vláken dosáhne "minimálního" počtu vláken, fond vláken omezí rychlost, s jakou vloží nová vlákna na jedno vlákno za 500 milisekund. Obvykle platí, že pokud váš systém dostane nárůst práce, který potřebuje vlákno IOCP, zpracuje to rychle. Pokud je však nárůst větší než nakonfigurované nastavení Minimum, je při zpracování některé práce zpoždění, protože fond vláken čeká na jednu ze dvou možností:

• Stávající vlákno se uvolní ke zpracování práce.
• Žádné existující vlákno se stane zdarma pro 500 ms a vytvoří se nové vlákno.

V podstatě platíte, že pokud je počet vláken Zaneprázdněn větší než minimální počet vláken, pravděpodobně platíte zpoždění 500 ms před zpracováním síťového provozu aplikací. Navíc, když existující vlákno zůstane nečinné déle než 15 sekund, vyčistí se a tento cyklus růstu a zmenšení se může opakovat.

Pokud se podíváme na ukázkovou chybovou zprávu z StackExchange.Redis (build 1.0.450 nebo novější), vidíme, že teď vytiskne statistiku ThreadPool. Podrobnosti o IOCP a WORKER najdete níže.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Jak je znázorněno v příkladu, vidíte, že pro vlákno IOCP existuje šest zaneprázdněných vláken a systém je nakonfigurovaný tak, aby umožňoval čtyři minimální vlákna. V tomto případě by se klientovi zobrazily dvě zpoždění 500 ms, protože 6 > 4.

Doporučení

Vzhledem k tomuto informacím důrazně doporučujeme zákazníkům nastavit minimální hodnotu konfigurace pro vlákna IOCP a WORKER na něco většího než výchozí hodnota. Nemůžeme poskytnout pokyny pro to, co by tato hodnota měla být, protože správná hodnota pro jednu aplikaci může být příliš vysoká nebo nízká pro jinou aplikaci. Toto nastavení může také ovlivnit výkon jiných částí složitých aplikací, takže každý zákazník musí toto nastavení doladit podle svých konkrétních potřeb. Dobré počáteční místo je 200 nebo 300, pak otestujte a upravte podle potřeby.

Jak nakonfigurovat toto nastavení:

• Toto nastavení doporučujeme změnit programově pomocí metody ThreadPool.SetMinThreads (...) v global.asax.cs. Příklad:

  private readonly int minThreads = 200;
  void Application_Start(object sender, EventArgs e)
  {
      // Code that runs on application startup
      AreaRegistration.RegisterAllAreas();
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);
      ThreadPool.SetMinThreads(minThreads, minThreads);
  }
  

  Poznámka:

  Hodnota zadaná touto metodou je globální nastavení, které má vliv na celou doménu AppDomain. Pokud máte například počítač se čtyřmi jádry a chcete nastavit minWorkerThreads a minIoThreads na 50 na procesor během běhu, použijte ThreadPool.SetMinThreads(200; 200).

• Je také možné určit minimální nastavení vláken pomocí nastavení konfigurace minIoThreads nebo minWorkerThreads pod <processModel> elementem konfigurace v Machine.config. Machine.config se obvykle nachází na %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\adrese . Nastavení minimálního počtu vláken tímto způsobem se nedoporučuje, protože se jedná o nastavení pro celý systém.

  Poznámka:

  Hodnota zadaná v tomto elementu konfigurace je nastavení pro každé jádro . Pokud máte například počítač se čtyřmi jádry a chcete , aby nastavení minIoThreads bylo za běhu 200, použili <processModel minIoThreads="50"/>byste .

Povolení serverového uvolňování paměti může optimalizovat klienta a zajistit lepší výkon a propustnost při použití StackExchange.Redis. Další informace o serveru GC a jeho povolení najdete v následujících článcích:

• Povolení serveru GC
• Základy kolekce paměti
• Kolekce paměti a výkon

Různé skladové položky můžou mít různá omezení pro připojení klientů, paměť a šířku pásma. I když každá velikost mezipaměti umožňuje až určitý počet připojení, každé připojení k Redis má spojené režijní náklady. Příkladem takové režie by bylo využití procesoru a paměti kvůli šifrování TLS/SSL. Maximální limit připojení pro danou velikost mezipaměti předpokládá mírně načtenou mezipaměť. Pokud zatížení z režie připojení plus zatížení z klientských operací překročí kapacitu systému, může do mezipaměti docházet k problémům s kapacitou i v případě, že nepřekročíte limit připojení pro aktuální velikost mezipaměti.

Další informace o různých limitech připojení pro každou úroveň najdete v cenách Azure Managed Redis. Další informace o připojeních a dalších výchozích konfiguracích najdete v tématu Výchozí konfigurace serveru Redis.

Další kroky

Seznamte se s dalšími nejčastějšími dotazy ke službě Azure Managed Redis.