Azure Cache voor Redis veelgestelde vragen over beheer

Redis-server biedt geen systeemeigen ondersteuning voor TLS, maar Azure Cache voor Redis wel. Als u verbinding maakt met Azure Cache voor Redis en uw client TLS ondersteunt, zoals StackExchange.Redis, gebruikt u TLS.

Redis-hulpprogramma's, zoals redis-cli niet werken met de TLS-poort, maar u kunt een hulpprogramma gebruiken, zoals stunnel het veilig verbinden van de hulpprogramma's met de TLS-poort door de aanwijzingen te volgen in de aankondiging van ASP.NET Sessiestatusprovider voor Redis Preview-blogpost .

Zie de sectie Redis-opdrachten uitvoeren voor instructies over het downloaden van de Redis-hulpprogramma's.

• Best practices voor StackExchange.Redis
• Configuratie en concepten
• Prestaties testen

Best practices voor StackExchange.Redis

• Stel AbortConnect deze in op false en laat de ConnectionMultiplexer automatisch opnieuw verbinding maken.
• Gebruik één exemplaar met een lange levensduur ConnectionMultiplexer in plaats van een nieuwe verbinding te maken voor elke aanvraag. Zie de RedisConnection klasse in Verbinding maken met de cache met behulp van RedisConnection voor een voorbeeld van het beheren van een verbinding.
• Redis werkt het beste met kleinere waarden, dus overweeg om grotere gegevens in meerdere sleutels op te slaan. In deze Redis-discussie wordt 100 kb als groot beschouwd. Zie De ontwikkeling van best practices voor meer informatie.
• Configureer de ThreadPool-instellingen om time-outs te voorkomen.
• Gebruik ten minste de standaard connectTimeout van 5 seconden. Dit interval geeft StackExchange.Redis voldoende tijd om de verbinding opnieuw tot stand te brengen als er een netwerklip is.
• Houd rekening met de prestatiekosten die zijn gekoppeld aan verschillende bewerkingen die u uitvoert. De KEYS opdracht is bijvoorbeeld een O(n)-bewerking en moet worden vermeden. De redis.io-site bevat details over de tijdscomplexiteit voor elke bewerking die wordt ondersteund. Selecteer elke opdracht om de complexiteit voor elke bewerking te bekijken.

Configuratie en concepten

• Gebruik de Standard- of Premium-laag voor productiesystemen. De laag Basic is een systeem met één knooppunt zonder gegevensreplicatie en zonder SLA. Gebruik minimaal een C1-cache. C0-caches worden doorgaans gebruikt voor eenvoudige ontwikkel-/testscenario's.
• Redis is een gegevensarchief in het geheugen . Zie Problemen met gegevensverlies in Azure Cache voor Redis oplossen, zodat u op de hoogte bent van scenario's waarin gegevensverlies kan optreden.
• Ontwikkel uw systeem zodanig dat het verbindingslips kan verwerken die worden veroorzaakt door patching en failover.

Prestatietesten

• Begin met het gebruik redis-benchmark.exe om een idee te krijgen van mogelijke doorvoer voordat u uw eigen prestatietests schrijft. Omdat redis-benchmark TLS niet wordt ondersteund, moet u de niet-TLS-poort via Azure Portal inschakelen voordat u de test uitvoert. Zie Hoe kan ik de prestaties van mijn cache benchmarken en testen?
• De client-VM die wordt gebruikt voor testen, moet zich in dezelfde regio bevinden als uw Azure Cache voor Redis-exemplaar.
• We raden u aan de Dv2 VM-serie te gebruiken voor uw client omdat ze betere hardware hebben en de beste resultaten moeten opleveren.
• Zorg ervoor dat de client-VM die u kiest minstens zoveel reken- en bandbreedtemogelijkheden heeft als de cache die u test.
• Schakel VRSS in op de clientcomputer als u windows gebruikt. Zie hier voor meer informatie.
• Redis-exemplaren van de Premium-laag hebben een betere netwerklatentie en doorvoer omdat ze worden uitgevoerd op betere hardware voor zowel CPU als netwerk.

• Vermijd het gebruik van bepaalde Redis-opdrachten die lang duren, tenzij u het resultaat van deze opdrachten volledig begrijpt. Voer bijvoorbeeld de opdracht SLEUTELS niet uit in productie. Afhankelijk van het aantal sleutels kan het lang duren om terug te keren. Redis is een server met één thread en verwerkt opdrachten één voor één. Als u andere opdrachten hebt uitgegeven na SLEUTELS, worden deze pas verwerkt nadat Redis de opdracht KEYS verwerkt. De redis.io-site bevat details over de tijdscomplexiteit voor elke bewerking die wordt ondersteund. Selecteer elke opdracht om de complexiteit voor elke bewerking te bekijken.
• Sleutelgrootten: moet ik kleine sleutel/waarden of grote sleutel/waarden gebruiken? Dit hangt af van het scenario. Als voor uw scenario grotere sleutels nodig zijn, kunt u connectionTimeout aanpassen, waarden opnieuw proberen en de logica voor opnieuw proberen aanpassen. Vanuit het perspectief van een Redis-server zorgen kleinere waarden voor betere prestaties.
• Deze overwegingen betekenen niet dat u geen grotere waarden kunt opslaan in Redis; U moet rekening houden met de volgende overwegingen. Latenties zijn hoger. Als u één set gegevens hebt die groter is en kleiner is, kunt u meerdere ConnectionMultiplexer-exemplaren gebruiken. Configureer elk met een andere set time-out- en nieuwe waarden, zoals beschreven in de vorige sectie Wat doen de configuratieopties van StackExchange.Redis.

• Schakel de diagnostische gegevens van de cache in, zodat u de status van de cache kunt bewaken. U kunt de metrische gegevens weergeven in Azure Portal. U kunt ze ook downloaden en bekijken met een hulpprogramma van uw keuze.
• U kunt redis-benchmark.exe gebruiken om uw Redis-server te testen.
• Zorg ervoor dat de client voor belastingstests en de Azure Cache voor Redis zich in dezelfde regio bevinden.
• Gebruik redis-cli.exe en bewaak de cache met behulp van de opdracht INFO.
• Als uw belasting een hoge geheugenfragmentatie veroorzaakt, moet u omhoog schalen naar een grotere cachegrootte.
• Zie de sectie Redis-opdrachten uitvoeren voor instructies over het downloaden van de Redis-hulpprogramma's.

Hier volgen enkele voorbeelden van het gebruik van redis-benchmark.exe. Voer deze opdrachten uit vanaf een VIRTUELE machine in dezelfde regio als uw cache voor nauwkeurige results.cache-development-faq.yml

• Pijplijn-SET-aanvragen testen met behulp van een nettolading van 1 k

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

• Test GET-aanvragen met pijplijn met behulp van een nettolading van 1.000.

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

De CLR ThreadPool heeft twee typen threads: IOCP-threads (Worker) en I/O-voltooiingspoort.

• Werkrolthreads worden gebruikt voor zaken zoals het verwerken van of Task.Run(…)ThreadPool.QueueUserWorkItem(…) methoden. Deze threads worden ook gebruikt door verschillende onderdelen in de CLR wanneer werk moet plaatsvinden op een achtergrondthread.
• IOCP-threads worden gebruikt wanneer asynchrone IO plaatsvindt, zoals bij het lezen van het netwerk.

De threadgroep biedt nieuwe werkthreads of I/O-voltooiingsthreads op aanvraag (zonder enige beperking) totdat de instelling 'Minimum' voor elk type thread wordt bereikt. Standaard is het minimum aantal threads ingesteld op het aantal processors op een systeem.

Zodra het aantal bestaande (bezet) threads het 'minimum' aantal threads bereikt, beperkt de ThreadPool de snelheid waarmee nieuwe threads per 500 milliseconden worden geïnjecteerd. Als uw systeem meestal een piek aan werk krijgt waarvoor een IOCP-thread nodig is, wordt dat snel verwerkt. Als de burst echter meer is dan de geconfigureerde instelling 'Minimum', is er enige vertraging bij het verwerken van een deel van het werk, omdat de ThreadPool wacht op een van de twee mogelijkheden:

• Een bestaande thread wordt vrij om het werk te verwerken.
• Er wordt geen bestaande thread gratis voor 500 ms en er wordt een nieuwe thread gemaakt.

Als het aantal bezet-threads groter is dan minimale threads, betaalt u waarschijnlijk een vertraging van 500 ms voordat het netwerkverkeer door de toepassing wordt verwerkt. Wanneer een bestaande thread langer dan 15 seconden inactief blijft, wordt deze opgeschoond en kan deze cyclus van groei en verkleining worden herhaald.

Als we een voorbeeld van een foutbericht van StackExchange.Redis (build 1.0.450 of hoger) bekijken, zien we dat er nu ThreadPool-statistieken worden afgedrukt. Zie de details van IOCP en WORKER hieronder.

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)

Zoals in het voorbeeld wordt weergegeven, ziet u dat er voor IOCP-thread zes drukke threads zijn en dat het systeem is geconfigureerd om vier minimale threads toe te staan. In dit geval zou de client waarschijnlijk twee vertragingen van 500 ms hebben gezien, omdat 6 > 4.

Aanbeveling

Op basis van deze informatie raden we klanten ten zeerste aan om de minimale configuratiewaarde voor IOCP- en WORKER-threads in te stellen op iets dat groter is dan de standaardwaarde. We kunnen niet alle richtlijnen geven voor wat deze waarde moet zijn, omdat de juiste waarde voor de ene toepassing waarschijnlijk te hoog of laag is voor een andere toepassing. Deze instelling kan ook van invloed zijn op de prestaties van andere onderdelen van complexe toepassingen, zodat elke klant deze instelling moet afstemmen op hun specifieke behoeften. Een goede startplaats is 200 of 300, en test en pas deze aan waar nodig.

Deze instelling configureren:

• U wordt aangeraden deze instelling programmatisch te wijzigen met behulp van de methode ThreadPool.SetMinThreads (...) in global.asax.cs. Bijvoorbeeld:

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

  Notitie

  De waarde die door deze methode wordt opgegeven, is een globale instelling die van invloed is op het hele AppDomain. Als u bijvoorbeeld een 4-core machine hebt en minWorkerThreads en minIoThreads wilt instellen op 50 per CPU tijdens de runtime, gebruikt u ThreadPool.SetMinThreads(200, 200).

• Het is ook mogelijk om de minimale threads-instelling op te geven met behulp van de configuratie-instelling minIoThreads of minWorkerThreads onder het <processModel> configuratie-element in Machine.config. Machine.config bevindt zich meestal in %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Het instellen van het aantal minimale threads op deze manier wordt niet aanbevolen omdat dit een systeembrede instelling is.

  Notitie

  De waarde die is opgegeven in dit configuratie-element is een instelling per kern . Als u bijvoorbeeld een 4-core machine hebt en wilt dat de instelling minIoThreads tijdens runtime 200 is, gebruikt <processModel minIoThreads="50"/>u .

Server GC inschakelen kan de client optimaliseren en betere prestaties en doorvoer bieden bij gebruik van StackExchange.Redis. Zie de volgende artikelen voor meer informatie over server GC en hoe u deze inschakelt:

• Server GC inschakelen
• Grondbeginselen van garbagecollection
• Garbagecollection en prestaties

Elke prijscategorie heeft verschillende limieten voor clientverbindingen, geheugen en bandbreedte. Hoewel elke cachegrootte maximaal een aantal verbindingen toestaat, heeft elke verbinding met Redis overhead gekoppeld. Een voorbeeld van dergelijke overhead is CPU- en geheugengebruik vanwege TLS/SSL-versleuteling. Bij de maximale verbindingslimiet voor een bepaalde cachegrootte wordt uitgegaan van een licht geladen cache. Als de belasting van verbindingsoverhead plus belasting van clientbewerkingen de capaciteit voor het systeem overschrijdt, kan de cache capaciteitsproblemen ondervinden, zelfs als u de verbindingslimiet voor de huidige cachegrootte niet hebt overschreden.

Zie Azure Cache voor Redis prijzen voor meer informatie over de verschillende verbindingslimieten voor elke laag. Zie De standaardconfiguratie van de Redis-server voor meer informatie over verbindingen en andere standaardconfiguraties.

Volgende stappen

Meer informatie over andere Azure Cache voor Redis veelgestelde vragen.