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

Tento článek obsahuje odpovědi na běžné otázky týkající se správy Azure Managed Redis.

Kdy mám povolit port pro připojení ke službě Redis, který nepoužívá protokol TLS/SSL?

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.

Jaké jsou některé osvědčené postupy v produkčním prostředí?

• 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ého limitu.
• 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.

Co je potřeba vzít v úvahu při používání běžných příkazů 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 opakováním hodnot, jak je popsáno v předchozí části Možnosti konfigurace StackExchange.Redis .

Jak můžu testovat a testovat výkon mezipaměti?

• Povolte diagnostiku mezipaměti, abyste mohli sledovat její stav. 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.

Důležité podrobnosti o růstu fondu vláken

Fond vláken CLR má dva typy vláken – vlákna pro dokončení pracovního procesu a vstupně-výstupních operací (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 zaneprázdněných vláken větší než minimální počet vláken, pravděpodobně platíte zpoždění 500 ms před tím, než aplikace zpracuje síťový provoz. 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 dále v článku.

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.

Poznámka:

StackExchange.Redis může dojít k vypršení časových limitů, pokud dojde k omezení růstu vláken IOCP nebo WORKER.

Doporučení

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 tuto hodnotu, 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 mít vliv i na výkon jiných částí komplikovaných aplikací. 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 programově změnit pomocí metody ThreadPool.SetMinThreads (...) v aplikacích .NET Framework a .NET Core.

Například v rozhraní NET Framework ho Global.asax.cs nastavíte v Application_Start metodě:

```csharp
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);
}
```

Pokud používáte .NET Core, nastavte ho těsně Program.cspřed voláním na WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

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 během běhu nastavit minWorkerThreads a minIoThreads na 50 procesorů, použijte ThreadPool.SetMinThreads(200, 200).

Je také možné určit minimální nastavení vláken pomocí minIoThreads nastavení nebo minWorkerThreadsnastavení konfigurace pod prvkem <processModel> 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í platné pro celý systém. Pokud ho nastavíte tímto způsobem, musíte restartovat fond aplikací.

Poznámka:

Hodnota zadaná v tomto elementu konfigurace je nastavení pro každé jádro . Pokud máte například čtyřjádrový počítač a chcete, aby vaše minIoThreads nastavení bylo 200 za běhu, použijte <processModel minIoThreads="50">.

Povolení uvolňování paměti serveru pro získání větší propustnosti klienta při použití StackExchange.Redis

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 Garbage Collection
• Kolekce paměti a výkon

Aspekty výkonu týkající se připojení

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.

Související obsah

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

Tento článek obsahuje odpovědi na běžné otázky týkající se správy Azure Managed Redis.

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ého limitu.
• 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 opakováním hodnot, jak je popsáno v předchozí části Možnosti konfigurace StackExchange.Redis .

• Povolte diagnostiku mezipaměti, abyste mohli sledovat její stav. 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 – vlákna pro dokončení pracovního procesu a vstupně-výstupních operací (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 zaneprázdněných vláken větší než minimální počet vláken, pravděpodobně platíte zpoždění 500 ms před tím, než aplikace zpracuje síťový provoz. 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 dále v článku.

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.

Poznámka:

StackExchange.Redis může dojít k vypršení časových limitů, pokud dojde k omezení růstu vláken IOCP nebo WORKER.

Doporučení

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 tuto hodnotu, 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 mít vliv i na výkon jiných částí komplikovaných aplikací. 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 programově změnit pomocí metody ThreadPool.SetMinThreads (...) v aplikacích .NET Framework a .NET Core.

Například v rozhraní NET Framework ho Global.asax.cs nastavíte v Application_Start metodě:

```csharp
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);
}
```

Pokud používáte .NET Core, nastavte ho těsně Program.cspřed voláním na WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

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 během běhu nastavit minWorkerThreads a minIoThreads na 50 procesorů, použijte ThreadPool.SetMinThreads(200, 200).

Je také možné určit minimální nastavení vláken pomocí minIoThreads nastavení nebo minWorkerThreadsnastavení konfigurace pod prvkem <processModel> 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í platné pro celý systém. Pokud ho nastavíte tímto způsobem, musíte restartovat fond aplikací.

Poznámka:

Hodnota zadaná v tomto elementu konfigurace je nastavení pro každé jádro . Pokud máte například čtyřjádrový počítač a chcete, aby vaše minIoThreads nastavení bylo 200 za běhu, použijte <processModel minIoThreads="50">.

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 Garbage Collection
• 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.

Související obsah

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