Nejčastější dotazy ke správě Azure Cache for Redis

Server Redis nativně nepodporuje protokol TLS, ale Azure Cache for Redis funguje. Pokud se připojujete ke službě Azure Cache for Redis a váš klient podporuje protokol TLS, jako je StackExchange.Redis, použijte protokol TLS.

Nástroje Redis, jako redis-cli například nefungují s portem TLS, ale můžete použít nástroj, například stunnel k bezpečnému připojení nástrojů k portu TLS podle pokynů v blogovém příspěvku Oznámení o ASP.NET poskytovateli stavu relace pro verzi Redis Preview.

Pokyny ke stažení nástrojů Redis najdete v části Jak spustit příkazy Redis?

• 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 této 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

• Pro produkční systémy použijte úroveň Standard nebo Premium. Úroveň Basic odpovídá systému s jedním uzlem bez replikace dat a smlouvy SLA. Jako mezipaměť použijte aspoň C1. Mezipaměti C0 se obvykle používají pro jednoduché scénáře vývoje/testování.
• 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 Cache for 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

• Začněte tím, že použijete redis-benchmark.exe k získání pocitu možné propustnosti před zápisem vlastníchtestůch Vzhledem k tomu redis-benchmark , že protokol TLS nepodporuje, musíte před spuštěním testu povolit port bez tls prostřednictvím webu Azure Portal . Příklady najdete v tématu Jak můžu provést srovnávací testy a otestovat výkon mezipaměti?
• Klientský virtuální počítač použitý k testování by měl být ve stejné oblasti jako vaše instance Azure Cache for Redis.
• Pro klienta doporučujeme používat řadu virtuálních počítačů Dv2, protože mají lepší hardware a měli by poskytovat nejlepší výsledky.
• Ujistěte se, že zvolený klientský virtuální počítač má alespoň tolik výpočetních a šířky pásma jako mezipaměť, kterou testujete.
• Pokud používáte Windows, povolte VRSS na klientském počítači. Podrobnosti najdete tady.
• Instance Redis úrovně Premium mají lepší latenci a propustnost sítě, protože běží na lepším hardwaru pro procesor i síť.

• 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. Redis je server s jedním vláknem 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 budou 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.
• K zátěžové zátěži serveru Redis můžete použít redis-benchmark.exe.
• Ujistěte se, že klient zátěžového testování a Azure Cache for Redis jsou ve stejné oblasti.
• Použijte redis-cli.exe a monitorujte mezipaměť pomocí příkazu INFO.
• Pokud zatížení způsobuje vysokou fragmentaci paměti, měli byste vertikálně navýšit kapacitu na větší velikost mezipaměti.
• Pokyny ke stažení nástrojů Redis najdete v části Jak spustit příkazy Redis?

Tady je několik příkladů použití redis-benchmark.exe. Spuštění těchto příkazů z virtuálního počítače ve stejné oblasti jako mezipaměť pro přesné results.cache-development-faq.yml

• Testování požadavků SET kanálu pomocí datové části 1k

  redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

• Otestujte požadavky GET kanálu pomocí datové části 1k.

redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

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í. Pokud 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 takovém případě by klient pravděpodobně zaznamenal 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 bude pravděpodobně 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 4jádrový počítač a chcete nastavit minWorkerThreads a minIoThreads na 50 na procesor během běhu, použijte ThreadPool.SetMinThreads(200, 200).

• Nastavení minimálních vláken je také možné určit 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 4jádrový počítač 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

Každá cenová úroveň má 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 když jste nepřekročili limit připojení pro aktuální velikost mezipaměti.

Další informace o různých omezeních připojení pro jednotlivé úrovně najdete v tématu Ceny služby Azure Cache for 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

Přečtěte si další nejčastější dotazy ke službě Azure Cache for Redis.