Serverbelasting beheren voor Azure Cache voor Redis
Waardegrootten
Het ontwerp van uw clienttoepassing bepaalt of u veel kleine waarden of een kleiner aantal grotere waarden moet opslaan. Vanuit het perspectief van een Redis-server zorgen kleinere waarden voor betere prestaties. U wordt aangeraden de waarde lager dan 100 kB te houden.
Als uw ontwerp vereist dat u grotere waarden opslaat in de Azure Cache voor Redis, wordt de serverbelasting hoger. In dat geval moet u mogelijk een hogere cachelaag gebruiken om ervoor te zorgen dat het CPU-gebruik de doorvoer niet beperkt.
Zelfs als de cache over voldoende CPU-capaciteit beschikt, verhogen grotere waarden de latentie. Volg daarom de richtlijnen in Geschikte time-outs configureren.
Grotere waarden vergroten ook de kans op geheugenfragmentatie, dus zorg ervoor dat u de richtlijnen volgt in De instelling voor maxmemory-reserved configureren.
Pieken in clientverbindingen voorkomen
Het maken en sluiten van verbindingen is een dure bewerking voor de Redis-server. Als uw clienttoepassing in korte tijd te veel verbindingen maakt of sluit, kan dit de Redis-server sterk belasten.
Als u veel clientexemplaren instantiëert om in één keer verbinding te maken met Redis, kunt u overwegen om het maken van nieuwe verbindingen te faseren om een steile piek in het aantal verbonden clients te voorkomen.
Geheugendruk
Hoog geheugengebruik op de server maakt het waarschijnlijker dat het systeem gegevens op schijf moet plaatsen, wat resulteert in paginafouten die het systeem aanzienlijk kunnen vertragen.
Langdurige opdrachten vermijden
Redis-server is een systeem met één thread. Langlopende opdrachten kunnen latentie of time-outs aan de clientzijde veroorzaken omdat de server niet kan reageren op andere aanvragen terwijl deze bezig is met een langlopende opdracht. Zie Problemen met Azure Cache voor Redis aan de serverzijde oplossen voor meer informatie.
Serverbelasting bewaken
Voeg bewaking van serverbelasting toe om ervoor te zorgen dat u meldingen krijgt wanneer de serverbelasting hoog is. Met bewaking krijgt u inzicht in de beperkingen van uw toepassing. Vervolgens kunt u proactief werken om problemen te verhelpen. U wordt aangeraden de serverbelasting onder de 80% te houden om slechte prestaties te voorkomen. Langdurige serverbelasting van meer dan 80% kan leiden tot ongeplande failovers. Momenteel worden in Azure Cache voor Redis twee metrische gegevens weergegeven in Insights onder Bewaking in het menu Resource aan de linkerkant van de portal: CPU en serverbelasting. Bij het bewaken van de serverbelasting is het belangrijk om te begrijpen wat er door elk metrische waarde wordt gemeten.
De metrische CPU-waarde geeft het CPU-gebruik aan voor het knooppunt dat als host fungeert voor de cache. De metrische CPU-waarde bevat ook processen die niet uitsluitend Redis-serverprocessen zijn. De CPU omvat achtergrondprocessen voor antimalware en dergelijke. Als gevolg hiervan kan de metrische CPU-waarde soms pieken vertonen en is deze mogelijk geen perfecte indicator voor het CPU-gebruik van de Redis-server.
De metrische gegevens voor serverbelasting vertegenwoordigen alleen de belasting op de Redis-server. U wordt aangeraden de metrische gegevens voor serverbelasting te bewaken in plaats van CPU.
Bij het bewaken van de serverbelasting raden we u ook aan om de maximale pieken van serverbelasting te onderzoeken in plaats van gemiddeld, omdat zelfs korte pieken failovers en time-outs voor opdrachten kunnen activeren.
Serveronderhoud plannen
Zorg ervoor dat u voldoende servercapaciteit hebt om uw piekbelasting te verwerken tijdens het onderhoud van uw cacheservers. Test uw systeem door knooppunten opnieuw te starten tijdens piekbelasting. Zie opnieuw opstarten voor meer informatie over het simuleren van de implementatie van een patch.
Testen op verhoogde serverbelasting na failover
Voor Standard en Premium SKU's wordt elke cache gehost op twee knooppunten. Een load balancer verdeelt de clientverbindingen over de twee knooppunten. Wanneer gepland of ongepland onderhoud plaatsvindt op het primaire knooppunt, sluit het knooppunt alle clientverbindingen. In dergelijke situaties kunnen alle clientverbindingen op één knooppunt terechtkomen, waardoor de belasting van de server op het ene resterende knooppunt toeneemt. U wordt aangeraden dit scenario te testen door het primaire knooppunt opnieuw te starten en ervoor te zorgen dat één knooppunt alle clientverbindingen kan verwerken zonder dat de serverbelasting te hoog wordt.