Veelgestelde vragen over Azure Managed Redis-beheer (preview)

Het gebruik van TLS wordt aanbevolen als best practice in vrijwel alle Redis-gebruiksvoorbeelden. De optie om verbinding te maken zonder TLS is opgenomen voor compatibiliteitsdoeleinden met eerdere versies.

• 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.
• Redis werkt het beste met kleinere waarden, dus overweeg om grotere gegevens in meerdere sleutels op te slaan. In de 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

• Redis is een gegevensarchief in het geheugen . Zie Problemen met gegevensverlies in Azure Managed Redis oplossen, zodat u zich bewust 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

• Zie Prestatietests met Azure Managed Redis , bijvoorbeeld benchmarks en instructies voor het uitvoeren van uw eigen prestatietests op Azure Managed Redis.

• 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. Elke Redis-shard is éé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.
• Zie Prestatietests met Azure Managed Redis , bijvoorbeeld benchmarks en instructies voor het uitvoeren van uw eigen prestatietests op Azure Managed Redis.

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 worden geïnjecteerd in één thread per 500 milliseconden. Als uw systeem 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 ziet de client twee vertragingen van 500 ms, 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 geen richtlijnen geven die geschikt zijn voor één grootte, omdat de juiste waarde voor de ene toepassing te hoog of laag kan zijn 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 machine met vier kernen 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 machine met vier kernen hebt en u 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

Verschillende SKU's kunnen verschillende limieten hebben 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 overschrijdt.

Zie de prijzen van Azure Managed Redis 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 veelgestelde vragen over Azure Managed Redis.