Vanliga frågor och svar om cachehantering

• Används redis-benchmark.exe för att belastningstesta Redis-servern. Använd redis-benchmark.exe för att få en känsla för möjligt dataflöde innan du skriver egna prestandatester.
• Används redis-cli för att övervaka cachen med hjälp av INFO kommandot. Anvisningar om hur du laddar ned Redis-verktygen finns i Hur kan jag köra Redis-kommandon?
• Om du använder TLS/SSL (Transport Layer Security/Secure Socket Layer) på cacheinstansen --tls lägger du till parametern i Redis-tools-kommandona eller använder en proxy som stunnel för att aktivera TLS/SSL.
• Redis-benchmark Använder port 6379 som standard. -p Använd parametern för att åsidosätta den här inställningen om cacheminnet använder SSL/TLS-porten 6380 eller porten 10000på företagsnivå.
• Om det behövs kan du aktivera icke-TLS-porten via Azure Portal innan du kör belastningstestet.
• Kontrollera att den virtuella klientdatorn (VM) som du använder för testning finns i samma region som din Azure Cache for Redis-instans.
• Se till att den virtuella klientdatorn har minst lika mycket databehandlings- och bandbreddskapacitet som den cache som du testar. För bästa resultat bör du använda virtuella datorer i D-serien och E-serien för dina klienter.
• Om du använder Windows aktiverar du Virtual Receive-Side Scaling (VRSS) på klientdatorn. Mer information finns i Skalning på virtuell mottagningssida i Windows Server 2012 R2.
• Aktivera cachediagnostik så att du kan övervaka hälsotillståndet för cacheminnet. Du kan visa måtten i Azure Portal, och du kan även ladda ned och granska dina mått med hjälp av de verktyg du väljer.
• Om belastningen orsakar hög minnesfragmentering skalar du upp till en större cachestorlek.

I följande exempel visas hur du använder redis-benchmark.exe. Kör dessa kommandon från en virtuell dator i samma region som cacheminnet för korrekta resultat.

Testa först pipelined-begäranden SET med hjälp av en 1k-nyttolast:

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

När du har kört SET testet kör du pipelined-begäranden GET med hjälp av en 1k-nyttolast:

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

Genom att aktivera serverskräpinsamling (GC) kan du 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:

• Elementet <gcServer>
• Grunderna för skräpinsamling
• Skräpinsamling och prestanda

Redis-servern har inte inbyggt stöd för TLS (Transport Layer Security), men Azure Cache for Redis har stöd för TLS. Om du ansluter till Azure Cache for Redis med en klient som StackExchange.Redis som stöder TLS använder du TLS.

Om cachen använder TLS måste du aktivera TLS med hjälp av --tls alternativet för Redis-verktyg som redis-cli. Du kan också använda ett verktyg, 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 Announcing ASP.NET Session State Provider for Redis Preview Release .

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

• 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ådig server som bearbetar kommandon ett i taget. Om du utfärdar kommandot bearbetar Redis inte efterföljande kommandon förrän bearbetningen KEYSKEYS av kommandot är klar.

  Den redis.io platsen har information om tidskomplexitet för varje åtgärd som den stöder. Välj varje kommando för att se komplexiteten för varje åtgärd.

• Vilken storlek på nycklar som ska användas beror på scenariot. Om ditt scenario kräver större nycklar kan du justera och sedan försöka igen och justera logiken ConnectionTimeoutför återförsök. Ur ett Redis-serverperspektiv ger mindre nyckelvärden bättre prestanda.

• Dessa överväganden innebär inte att du inte kan lagra större värden i Redis, men svarstiderna är högre. Om du har en uppsättning data som är större än en annan kan du använda flera ConnectionMultiplexer instanser, var och en konfigurerad med en annan uppsättning timeout- och återförsöksvärden. Mer information finns i Vad gör konfigurationsalternativen för StackExchange.Redis?

Varje Azure Cache for Redis prisnivå har olika gränser för klientanslutningar, minne och bandbredd. Även om varje storlek på cacheminnet tillåter upp till ett visst antal anslutningar, innebär varje anslutning till Redis associerade omkostnader. Ett exempel på sådana omkostnader är CPU- 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 anslutningskostnaderna plus belastningen från klientåtgärder överskrider kapaciteten för systemet kan cachen uppleva kapacitetsproblem även om du inte överskrider anslutningsgränsen för den aktuella cachestorleken.

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

• Använd Standard- eller Premium-nivån för produktionssystem. Basic-nivån är ett system med en nod utan datareplikering och inget serviceavtal (SLA). Använd också minst en C1-cache för produktion. C0-cacheminnen används vanligtvis för enkla utvecklings-/testscenarier.
• Tänk på att Redis är ett minnesinternt datalager och att dataförlust kan inträffa i vissa scenarier. Mer information finns i Felsöka dataförlust i Azure Cache for Redis.
• Utveckla ditt system så att det kan hantera anslutningsproblem som orsakas av korrigeringar och redundans.
• Använd Azure Redis-instanser på Premium-nivå för bättre nätverksfördröjning och dataflöde, eftersom de har bättre maskinvara för både CPU och nätverk.

Metodtips för StackExchange.Redis

• Ställ in AbortConnect på ConnectionMultiplexer false och låt sedan återanslutningen 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 Vad är till exempel det idealiska värdestorleksintervallet för redis?, anses 100 kB vara stort. Mer information finns i Överväg fler nycklar och mindre värden.
• Konfigurera inställningarna för ThreadPool för att undvika tidsgränser.
• Använd minst standardvärdet connectTimeout 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 webbplatsen 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.

CLR (Common Language Runtime) ThreadPool har två typer av trådar, Worker- och I/O Completion Port (IOCP).

• WORKER Trådar används för saker som att bearbeta Task.Run(…), eller ThreadPool.QueueUserWorkItem(…) metoder. Olika komponenter i CLR använder också dessa trådar när arbete behöver ske på en bakgrundstråd.
• IOCP trådar används för asynkron I/O, till exempel vid läsning från nätverket.

Trådpoolen tillhandahåller nya arbetstrådar eller I/O-slutförandetrådar på begäran utan begränsning tills den minimum når inställningen 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 minimum trådnumret begränsar ThreadPool den hastighet med vilken den matar in nya trådar till en tråd per 500 millisekunder.

Om systemet får en mängd arbete som behöver en IOCP tråd bearbetar det vanligtvis det arbetet snabbt. Men om bursten är mer än den konfigurerade minimum inställningen 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 blir fri att bearbeta arbetet.
• Ingen befintlig tråd blir ledig under 500 ms, så en ny tråd skapas.

När antalet Busy trådar är större än Min trådar uppstår i princip en fördröjning på 500 ms innan programmet bearbetar nätverkstrafiken. Dessutom rensas en befintlig tråd som är inaktiv i mer än 15 sekunder, och den här cykeln av tillväxt och krympning kan upprepas.

Felmeddelanden från StackExchange.Redis version 1.0.450 eller senare skriver ut ThreadPool-statistik, som du ser i följande exempel.

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)

Exemplet visar att det för tråden IOCP finns sex upptagna trådar och att systemet är konfigurerat för att tillåta minst fyra trådar. I det här fallet kommer klienten sannolikt att se två fördröjningar på 500 ms, eftersom 6 > 4.

Det är bäst att ange det minsta konfigurationsvärdet för IOCP och WORKER trådar till något större än standardvärdet. Det finns ingen vägledning som passar alla om det här värdet, eftersom rätt värde för ett program troligen är för högt eller lågt för ett annat program. Den här inställningen kan också påverka prestanda för andra delar av komplicerade program. Du måste finjustera den här inställningen efter dina specifika behov. En bra utgångspunkt är 200 eller 300. Testa och justera sedan efter behov.

Konfigurera inställningen för minsta trådar

Du kan ändra den här inställningen programmatiskt med hjälp av metoden ThreadPool.SetMinThreads (... ).

I NET Framework anger du till exempel det här värdet i Global.asax.cs i Application_Start metoden:

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

Om du använder .NET Core anger du värdet i Program.cs precis före anropet till WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Det är också möjligt att ange inställningen för minsta trådar med hjälp av minIoThreadsminWorkerThreads eller under konfigurationselementet <processModel> i Machine.config. Machine.config finns vanligtvis på%SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Vi rekommenderar inte att du anger antalet minsta trådar på det här sättet eftersom det är en systemomfattande inställning. Om du anger minsta antal trådar på det här sättet måste du starta om programpoolen.

Relaterat innehåll

• Se andra vanliga frågor och svar om Azure Cache for Redis.