Vanliga frågor och svar om hantering för Azure Cache for Redis

Redis-servern har inte inbyggt stöd för TLS, men Azure Cache for Redis har det. Om du ansluter till Azure Cache for Redis och klienten stöder TLS, till exempel StackExchange.Redis, använder du TLS.

Redis-verktyg som redis-cli fungerar inte med TLS-porten, men du kan använda ett verktyg som till exempel stunnel för att på ett säkert sätt ansluta verktygen till TLS-porten genom att följa anvisningarna i blogginlägget Meddelande ASP.NET Sessionstillståndsprovider för Redis Preview Release.

Anvisningar om hur du laddar ned Redis-verktygen finns i avsnittet Hur kan jag köra Redis-kommandon?

• Metodtips för StackExchange.Redis
• Konfiguration och begrepp
• Prestandatestning

Metodtips för StackExchange.Redis

• Ange AbortConnect till false och låt sedan ConnectionMultiplexer återansluta automatiskt.
• Använd en enda, långlivad ConnectionMultiplexer instans i stället för att skapa en ny anslutning för varje begäran. Ett exempel på hur du hanterar en anslutning RedisConnection finns i klassen i Anslut till cachen med Redisconnection.
• Redis fungerar bäst med mindre värden, så överväg att dela upp större data i flera nycklar. I den här Redis-diskussionen anses 100 kb vara stort. Mer information finns i Metodtipsutveckling.
• Konfigurera inställningarna för ThreadPool för att undvika tidsgränser.
• Använd minst standardanslutningTidsgränsen på 5 sekunder. Det här intervallet ger StackExchange.Redis tillräckligt med tid för att återupprätta anslutningen om det finns en nätverksblip.
• Tänk på de prestandakostnader som är kopplade till olika åtgärder som du kör. Kommandot är till exempel KEYS en O(n) åtgärd och bör undvikas. Den redis.io platsen innehåller information om tidskomplexiteten för varje åtgärd som den stöder. Välj varje kommando för att se komplexiteten för varje åtgärd.

Konfiguration och begrepp

• Använd Standard- eller Premium-nivån för produktionssystem. Basic-nivån är ett system med en nod utan datareplikering och serviceavtal. Använd också minst ett C1-cacheminne. C0-cacheminnen används vanligtvis för enkla utvecklings-/testscenarier.
• Kom ihåg att Redis är ett minnesinternt datalager. Mer information finns i Felsöka dataförlust i Azure Cache for Redis så att du är medveten om scenarier där dataförlust kan inträffa.
• Utveckla systemet så att det kan hantera anslutningsblips som orsakas av korrigering och redundans.

Prestandatest

• Börja med att använda redis-benchmark.exe för att få en känsla för möjligt dataflöde innan du skriver dina egna perf-tester. Eftersom redis-benchmark inte stöder TLS måste du aktivera icke-TLS-porten via Azure Portal innan du kör testet. Exempel finns i Hur kan jag jämföra och testa prestanda för min cache?
• Den virtuella klientdatorn som används för testning bör finnas i samma region som din Azure Cache for Redis-instans.
• Vi rekommenderar att du använder Dv2 VM Series för din klient eftersom de har bättre maskinvara och bör ge bästa resultat.
• Kontrollera att den virtuella klientdator som du väljer har minst lika mycket databehandlings- och bandbreddskapacitet som den cache som du testar.
• Aktivera VRSS på klientdatorn om du använder Windows. Mer information finns här.
• Redis-instanser på Premium-nivå har bättre nätverkssvarstid och dataflöde eftersom de körs på bättre maskinvara för både CPU och nätverk.

• Undvik att använda vissa Redis-kommandon som tar lång tid att slutföra, såvida du inte förstår resultatet av dessa kommandon fullt ut. Kör till exempel inte kommandot KEYS i produktion. Beroende på antalet nycklar kan det ta lång tid att returnera. Redis är en entrådad server och bearbetar kommandon en i taget. Om du har andra kommandon som utfärdats efter NYCKLAR bearbetas de inte förrän Redis bearbetar KOMMANDOT NYCKLAR. Den redis.io platsen innehåller information om tidskomplexiteten för varje åtgärd som den stöder. Välj varje kommando för att se komplexiteten för varje åtgärd.
• Nyckelstorlekar – ska jag använda små nyckel/värden eller stora nyckel/värden? Det beror på scenariot. Om scenariot kräver större nycklar kan du justera ConnectionTimeout, sedan försöka igen och justera logiken för återförsök. Ur Redis-serverperspektiv ger mindre värden bättre prestanda.
• Dessa överväganden innebär inte att du inte kan lagra större värden i Redis. du måste vara medveten om följande överväganden. Svarstiderna blir högre. Om du har en uppsättning data som är större och en som är mindre kan du använda flera ConnectionMultiplexer-instanser. Konfigurera var och en med en annan uppsättning timeout- och återförsöksvärden, enligt beskrivningen i föregående avsnitt Vad gör konfigurationsalternativen StackExchange.Redis?

• Aktivera cachediagnostik så att du kan övervaka hälsotillståndet för cacheminnet. Du kan visa värdena på Azure-portalen eller hämta och granska dem med valfritt verktyg.
• Du kan använda redis-benchmark.exe för att läsa in test av Redis-servern.
• Kontrollera att belastningstestklienten och Azure Cache for Redis finns i samma region.
• Använd redis-cli.exe och övervaka cachen med hjälp av INFO-kommandot.
• Om belastningen orsakar hög minnesfragmentering bör du skala upp till en större cachestorlek.
• Anvisningar om hur du laddar ned Redis-verktygen finns i avsnittet Hur kan jag köra Redis-kommandon?

Här följer några exempel på hur du använder redis-benchmark.exe. Kör dessa kommandon från en virtuell dator i samma region som cacheminnet för korrekt results.cache-development-faq.yml

• Testa PIPELINED SET-begäranden med en nyttolast på 1 000

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

• Testa GET-begäranden i pipeline med en nyttolast på 1 000.

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

CLR ThreadPool har två typer av trådar – trådarna "Worker" och "I/O Completion Port" (IOCP).

• Arbetstrådar används för saker som bearbetning av Task.Run(…)metoderna eller ThreadPool.QueueUserWorkItem(…) . Dessa trådar används också av olika komponenter i CLR när arbetet måste utföras på en bakgrundstråd.
• IOCP-trådar används när asynkron I/O inträffar, till exempel vid läsning från nätverket.

Trådpoolen innehåller nya arbetstrådar eller I/O-slutförandetrådar på begäran (utan begränsning) tills den når inställningen "Minimum" för varje typ av tråd. Som standard anges det minsta antalet trådar till antalet processorer i ett system.

När antalet befintliga (upptagna) trådar når det "minsta" antalet trådar begränsar ThreadPool den hastighet med vilken den matar in nya trådar till en tråd per 500 millisekunder. Om systemet normalt får en mängd arbete som behöver en IOCP-tråd bearbetas det som fungerar snabbt. Men om burst-värdet är mer än den konfigurerade inställningen "Minimum" finns det en viss fördröjning i bearbetningen av en del av arbetet eftersom ThreadPool väntar på någon av två möjligheter:

• En befintlig tråd blir fri att bearbeta arbetet.
• Ingen befintlig tråd blir kostnadsfri för 500 ms och en ny tråd skapas.

När antalet upptagna trådar är större än Min-trådar betalar du förmodligen en fördröjning på 500 ms innan nätverkstrafiken bearbetas av programmet. När en befintlig tråd förblir inaktiv i mer än 15 sekunder rensas den också och den här cykeln av tillväxt och krympning kan upprepas.

Om vi tittar på ett exempel på ett felmeddelande från StackExchange.Redis (version 1.0.450 eller senare) ser vi att den nu skriver ut ThreadPool-statistik. Se information om IOCP och WORKER nedan.

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)

Som du ser i exemplet ser du att det för IOCP-tråden finns sex upptagna trådar och att systemet är konfigurerat för att tillåta fyra minsta trådar. I det här fallet skulle klienten sannolikt ha sett två fördröjningar på 500 ms, eftersom 6 > 4.

Rekommendation

Med den här informationen rekommenderar vi starkt att kunderna anger det minsta konfigurationsvärdet för IOCP- och WORKER-trådar till något större än standardvärdet. Vi kan inte ge vägledning som passar alla om vad det här värdet ska vara eftersom rätt värde för ett program sannolikt kommer att vara för högt eller lågt för ett annat program. Den här inställningen kan också påverka prestandan för andra delar av komplicerade program, så varje kund måste finjustera den här inställningen efter sina specifika behov. En bra startplats är 200 eller 300, sedan testa och justera efter behov.

Så här konfigurerar du den här inställningen:

• Vi rekommenderar att du ändrar den här inställningen programmatiskt med hjälp av metoden ThreadPool.SetMinThreads (...) i global.asax.cs. Till exempel:

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

  Kommentar

  Värdet som anges med den här metoden är en global inställning som påverkar hela AppDomain. Om du till exempel har en dator med 4 kärnor och vill ange minWorkerThreads och minIoThreads till 50 per CPU under körningen använder du ThreadPool.SetMinThreads(200, 200).

• Du kan också ange inställningen minsta antal trådar med hjälp av konfigurationsinställningen minIoThreads eller minWorkerThreads under <processModel> konfigurationselementet i Machine.config. Machine.config finns vanligtvis på %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Att ange antalet minsta trådar på det här sättet rekommenderas inte eftersom det är en systemomfattande inställning.

  Kommentar

  Värdet som anges i det här konfigurationselementet är en inställning per kärna . Om du till exempel har en dator med 4 kärnor och vill att minIoThreads-inställningen ska vara 200 vid körning använder <processModel minIoThreads="50"/>du .

Aktivering av server-GC kan optimera klienten och ge bättre prestanda och dataflöde när du använder StackExchange.Redis. Mer information om server-GC och hur du aktiverar den finns i följande artiklar:

• Så här aktiverar du server GC
• Grunderna i skräpinsamling
• Skräpinsamling och prestanda

Varje prisnivå har olika gränser för klientanslutningar, minne och bandbredd. Varje cachestorlek tillåter upp till ett antal anslutningar, men varje anslutning till Redis har kostnader associerade med den. Ett exempel på sådana omkostnader skulle vara processor- och minnesanvändning på grund av TLS/SSL-kryptering. Den maximala anslutningsgränsen för en viss cachestorlek förutsätter en lätt inläst cache. Om belastningen från anslutningskostnader plus belastning från klientåtgärder överskrider systemets kapacitet kan cachen uppleva kapacitetsproblem även om du inte har överskridit anslutningsgränsen för den aktuella cachestorleken.

Mer information om de olika anslutningsgränserna för varje nivå finns i Prissättning för Azure Cache for Redis. Mer information om anslutningar och andra standardkonfigurationer finns i Standardkonfiguration för Redis-server.

Nästa steg

Läs mer om andra vanliga frågor och svar om Azure Cache for Redis.