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 gör det. Om du ansluter till Azure Cache for Redis och klienten stöder TLS, t.ex. StackExchange.Redis, använder du TLS.

Redis-verktyg som redis-cli fungerar inte med TLS-porten, men du kan använda ett verktyg som stunnel för att på ett säkert sätt ansluta verktygen till TLS-porten genom att följa anvisningarna i blogginlägget Announcing ASP.NET Session State Provider for 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 timeouter.
• 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ätverks-blip.
• 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 anslutningsfel som orsakas av korrigeringar och redundans.

Prestandatestning

• Börja med att använda redis-benchmark.exe för att få en känsla för möjliga dataflöden innan du skriver dina egna prestandatester. 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 prestandatesta 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 möjliga resultat.
• Kontrollera att den virtuella klientdator som du väljer har minst lika mycket databehandlings- och bandbreddskapacitet som cachen 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ätverksfördröjning 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ärdas efter NYCKLAR bearbetas de inte förrän Redis bearbetar kommandot KEYS. 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å nycklar/värden eller stora nyckel/värden? Det beror på scenariot. Om ditt scenario kräver större nycklar kan du justera ConnectionTimeout och 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 för StackExchange.Redis ?

• Aktivera cachediagnostik så att du kan övervaka hälsotillståndet för cacheminnet. Du kan visa måtten i Azure Portal och du kan också ladda ned och granska dem med hjälp av de verktyg du väljer.
• 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 din cache för att få korrekta resultat.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 pipelines 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 – "Worker" och "I/O Completion Port" (IOCP) trådar.

• 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 arbete 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 är det minsta antalet trådar inställt på 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 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å en av två möjligheter:

• En befintlig tråd kan 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 är inaktiv längre ä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 det 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 är 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. 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);
  }
  

  Anteckning

  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 PROCESSOR under körningen använder du ThreadPool.SetMinThreads(200, 200).

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

  Anteckning

  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:

• Aktivera 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 visst 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 Azure Cache for Redis prissättning. 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.