Vanliga frågor och svar om Hantering av Azure Managed Redis (förhandsversion)

Användning av TLS rekommenderas som bästa praxis i praktiskt taget alla Redis-användningsfall. Alternativet att ansluta utan TLS ingår i bakåtkompatibilitetssyfte.

• 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.
• Redis fungerar bäst med mindre värden, så överväg att dela upp större data i flera nycklar. I 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

• Kom ihåg att Redis är ett minnesinternt datalager. Mer information finns i Felsöka dataförlust i Azure Managed 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

• Se Prestandatestning med Azure Managed Redis för exempel på prestandamått och instruktioner för att köra dina egna prestandatester på Azure Managed Redis.

• 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. Varje Redis-shard är en enkeltrådad partition 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 är 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.
• Se Prestandatestning med Azure Managed Redis för exempel på prestandamått och instruktioner för att köra dina egna prestandatester på Azure Managed Redis.

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 se 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 kan 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 fyra kärnor och vill ange minWorkerThreads och minIoThreads till 50 per CPU under körning använder du ThreadPool.SetMinThreads(200, 200).

• Du kan också ange inställningen för 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 fyra 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

Olika SKU:er kan ha 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 överskrider 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 Managed 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 Managed Redis.