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

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

Nástroje Redis, jako redis-cli je 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í ASP.NET poskytovatele stavu relace pro verzi Redis Preview .

Pokyny ke stažení nástrojů Redis najdete v části Jak můžu 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 na false a pak nechte ConnectionMultiplexer znovu připojit automaticky.
• Místo vytváření nového připojení pro každý požadavek použijte jednu dlouhodobou ConnectionMultiplexer instanci. Příklad správy připojení najdete v tématu RedisConnectiono třídě Připojení k mezipaměti pomocí redisconnection.
• Redis nejlépe funguje s menšími hodnotami, takže zvažte rozdělení větších dat do více klíčů. V této diskuzi o Redisu 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 alespoň výchozí connectTimeout 5 sekund. Tento interval poskytuje stackExchange.Redis dostatek času k opětovnému navázání připojení, pokud dojde k přerušení sítě.
• Mějte na paměti náklady na výkon spojené s různými operacemi, které spouštíte. Například příkaz KEYS je operace O(n) a je třeba se mu vyhnout. Web redis.io obsahuje podrobnosti o časové 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 a testování.
• Nezapomeňte, že Redis je úložiště dat v paměti . Další informace najdete v tématu Řešení potíží se ztrátou dat v Azure Cache for Redis, abyste měli přehled o scénářích, ve kterých může dojít ke ztrátě dat.
• Rozvíjejte systém tak, aby zvládl výpadky 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 , abyste si před psaním vlastních testů výkonu získali pocit možné propustnosti. Vzhledem k tomuredis-benchmark, že nepodporuje protokol TLS, musíte před spuštěním testu povolit port bez protokolu TLS prostřednictvím Azure Portal. Příklady najdete v tématu Jak můžu testovat a testovat 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.
• Doporučujeme pro klienta používat řadu virtuálních počítačů Dv2, protože má lepší hardware a měl by poskytovat nejlepší výsledky.
• Ujistěte se, že klientský virtuální počítač, který zvolíte, má alespoň stejnou výpočetní kapacitu a kapacitu šíř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íť.

• Nepoužívejte některé příkazy Redis, u kterých trvá dlouhou dobu, pokud plně nerozumíte výsledku těchto příkazů. Například nespouštět příkaz KEYS 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 postupně zpracovává příkazy. Pokud máte za příkazem KEYS vydané další příkazy, nezpracují se, dokud Redis nezpracuje příkaz KEYS. Web redis.io obsahuje podrobnosti o časové 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íč/hodnoty? Záleží na scénáři. Pokud váš scénář vyžaduje větší klíče, můžete upravit hodnotu ConnectionTimeout, pak zkusit hodnoty zopakovat a upravit logiku opakování. Z pohledu serveru Redis menší hodnoty poskytují lepší výkon.
• Tyto aspekty neznamenají, že v Redisu nemůžete ukládat větší hodnoty. musíte mít na paměti následující aspekty. Latence budou vyšší. Pokud máte jednu sadu dat, která je větší a jedna menší, můžete použít více instancí ConnectionMultiplexer. Nakonfigurujte každou z nich s jinou sadou hodnot časového limitu a opakování, jak je popsáno v předchozí části Co dělat možnosti konfigurace StackExchange.Redis .

• Povolte diagnostiku mezipaměti, abyste mohli monitorovat stav svojí mezipaměti. Metriky můžete zobrazit v Azure Portal a můžete si je také stáhnout a zkontrolovat pomocí nástrojů podle svého výběru.
• K zátěžovém testování serveru Redis můžete použít redis-benchmark.exe.
• Ujistěte se, že se klient zátěžového testování a Azure Cache for Redis nacházejí 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 můžu spustit příkazy Redis? .

Tady je několik příkladů použití redis-benchmark.exe. Spusťte tyto příkazy z virtuálního počítače ve stejné oblasti jako mezipaměť, abyste získáte přesné výsledky.cache-development-faq.yml

• Testování požadavků SET v 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 s kanálem 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í proces a port pro dokončení vstupně-výstupních operací (IOCP).

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

Fond vláken poskytuje nová pracovní vlákna nebo vlákna pro dokončování vstupně-výstupních operací na vyžádání (bez omezování), dokud nedosáhne minimálního nastavení 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 do jednoho vlákna na 500 milisekund. Obvykle platí, že pokud váš systém dostane velký nárůst práce, který vyžaduje vlákno IOCP, zpracuje práci rychle. Pokud je ale shluk větší než nakonfigurované nastavení Minimum, zpracování některých prací se zpožďuje, protože Fond vláken čeká na jednu ze dvou možností:

• Existující vlákno bude volně zpracovávat práci.
• Žádné existující vlákno se pro 500 ms neuvolní a vytvoří se nové vlákno.

V podstatě platí, ž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 smršťování se může opakovat.

Pokud se podíváme na ukázkovou chybovou zprávu ze služby StackExchange.Redis (build 1.0.450 nebo novější), uvidíme, že teď vytiskne statistiku Fondu vláken. Viz podrobnosti o IOCP a PRACOVNÍM PROCESU 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 minimálně čtyři vlákna. V tomto případě by klient pravděpodobně zaznamenal dvě zpoždění 500 ms, protože 6 > 4.

Doporučení

S ohledem na tyto informace důrazně doporučujeme, aby zákazníci nastavili minimální konfigurační hodnotu pro vlákna IOCP a WORKER na něco většího, než je výchozí hodnota. Nemůžeme poskytnout univerzální pokyny k tomu, 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 mít vliv také na 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ým výchozím místem je 200 nebo 300, pak otestujte a upravte podle potřeby.

Postup konfigurace tohoto nastavení:

• Toto nastavení doporučujeme změnit programově pomocí metody ThreadPool.SetMinThreads (...) v global.asax.cssouboru . Napří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 určená touto metodou je globální nastavení, které ovlivňuje celou doménu AppDomain. Pokud máte například počítač se 4 jádry a chcete nastavit hodnoty minWorkerThreads a minIoThreads na 50 na procesor za běhu, použijte ThreadPool.SetMinThreads(200, 200).

• Nastavení minimálního počtu vláken je také možné zadat pomocí konfiguračního nastavení minIoThreads nebo minWorkerThreads v elementu <processModel> konfigurace v Machine.config. Machine.config se obvykle nachází na adrese %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. 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 jednotlivá jádra . Pokud máte například počítač se 4 jádry a chcete, aby hodnota minIoThreads byla 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 uvolňování paměti serveru a o tom, jak ho povolit, najdete v následujících článcích:

• Povolení uvolňování paměti serveru
• Základy kolekce paměti
• Uvolňování 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í, s každým připojením k Redisu jsou spojené režijní náklady. Příkladem takové režie je 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í a zatížení z klientských operací překročí kapacitu systému, může docházet k problémům s kapacitou mezipaměti i v případě, že jste nepřekročili limit připojení pro aktuální velikost mezipaměti.

Další informace o různých limitech připojení pro jednotlivé úrovně najdete v tématu ceny 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 k Azure Cache for Redis.