Prestatietests met Azure Managed Redis

Het testen van de prestaties van een Redis-exemplaar kan een ingewikkelde taak zijn. De prestaties van een Redis-exemplaar kunnen variëren op basis van parameters zoals het aantal clients, de grootte van gegevenswaarden en of pipelining wordt gebruikt. Er kan ook een afweging zijn tussen het optimaliseren van doorvoer of latentie.

Gelukkig zijn er verschillende hulpprogramma's om benchmarking Redis eenvoudiger te maken. Twee van de populairste hulpprogramma's zijn redis-benchmark en memtier-benchmark . Dit artikel richt zich op memtier_benchmark, ook wel memtier genoemd.

Het hulpprogramma memtier_benchmark gebruiken

1. Installeer memtier op een virtuele clientmachine (VM's) die u kunt gebruiken voor testen. Volg de Memtier-documentatie voor instructies over het installeren van de opensource-installatiekopieën.

2. De virtuele clientmachine (VM) die wordt gebruikt voor testen, moet zich in dezelfde regio bevinden als uw Azure Managed Redis-exemplaar (WMV).

3. Zorg ervoor dat de client-VM die u gebruikt ten minste evenveel rekenkracht en bandbreedte heeft als het cache-exemplaar dat wordt getest.

4. Configureer uw netwerkisolatie en vm-firewallinstellingen om ervoor te zorgen dat de client-VM toegang heeft tot uw Azure Managed Redis-exemplaar.

5. Als u TLS/SSL op uw cache-exemplaar gebruikt, moet u de --tls en --tls-skip-verify parameters toevoegen aan de opdracht memtier_benchmark.

6. memtier_benchmark gebruikt standaard poort 6379. Gebruik de -p 10000 parameter om deze instelling te overschrijven, omdat WMV in plaats daarvan poort 10000 gebruikt.

7. Voor alle Beheerde Redis-exemplaren van Azure met behulp van het OSS-clusterbeleid moet u de parameter toevoegen aan de --cluster-mode memtier-opdracht. WMV-exemplaren die gebruikmaken van het enterprise-clusterbeleid kunnen worden behandeld als niet-geclusterde caches en hebben deze instelling niet nodig.

8. Start memtier_benchmark vanuit de CLI of shell van de VIRTUELE machine. Zie de documentatie van Memtier voor instructies over het configureren en uitvoeren van het hulpprogramma.

Aanbevelingen voor benchmarking

• Als u de prestaties die u nodig hebt niet krijgt, probeert u omhoog te schalen naar een geavanceerdere laag. De laag Balanced heeft doorgaans twee keer zoveel vCPU's als de laag Geoptimaliseerd voor geheugen en de laag Geoptimaliseerd voor rekenkracht heeft doorgaans twee keer zoveel vCPU's als de laag Balanced. Omdat Azure Managed Redis is gebouwd op Redis Enterprise in plaats van community Redis, kan het kernproces van Redis meerdere vCPU's gebruiken. Als gevolg hiervan hebben exemplaren met meer vCPU's aanzienlijk betere doorvoerprestaties.

• Door omhoog te schalen naar grotere geheugengrootten worden ook meer vCPU's toegevoegd, waardoor de prestaties toenemen. Het omhoog schalen naar grotere geheugengrootten is doorgaans minder effectief dan het gebruik van een beter presterende laag. Zie Lagen en SKU's in één oogopslag voor een gedetailleerde uitsplitsing van de vCPU's die beschikbaar zijn voor elke grootte en laag.

• Benchmarking van de laag Flash Optimized kan lastig zijn omdat sommige sleutels zijn opgeslagen op DRAM terwijl sommige worden opgeslagen op een NVMe-flashschijf. De sleutels op de DRAM-benchmark zijn bijna net zo snel als andere Beheerde Redis-exemplaren van Azure, maar de sleutels op de NVMe-flashschijf zijn langzamer. Omdat de laag Flash Geoptimaliseerd op intelligente wijze de meest gebruikte sleutels in DRAM plaatst, moet u ervoor zorgen dat uw benchmarkconfiguratie overeenkomt met het werkelijke gebruik dat u verwacht.

• Het gebruik van TLS/SSL vermindert de doorvoerprestaties, maar wordt ten zeerste aanbevolen als best practice voor productie.

• Het is essentieel om eerst het Redis-exemplaar met gegevens in te vullen voordat u benchmarkt. Benchmarking op een lege cache levert veel betere resultaten op dan u in de praktijk zou zien.

• Het aantal gebruikte verbindingen heeft een aanzienlijk effect op de benchmark. Het gebruik van te veel verbindingen begint de prestaties van de cache te verminderen. Het gebruik van te weinig verbindingen toont niet de volledige prestaties van de cache. We raden u aan het aantal verbindingen te configureren op basis van uw werkelijke toepassingsbehoeften. U bepaalt het totale aantal verbindingen door het aantal clients te vermenigvuldigen met het aantal threads.

• De pijplijnconfiguratie heeft een aanzienlijk effect op de prestatietests. Als u de pijplijninstelling instelt op groter, ziet u meer doorvoer, maar slechtere latentie. Zie pipelining voor meer informatie.

memtier_benchmark voorbeelden

Installatie vooraf testen: bereid het cache-exemplaar voor met gegevens die nodig zijn voor het testen. Het laden van het exemplaar met gegevens zorgt ervoor dat de resultaten nauwkeuriger overeenkomen met de werkelijke omstandigheden. De {number-of-keys} parameter moet worden bepaald door de grootte van uw AMR-exemplaar en de grootte van elke sleutel. Een goede vuistregel is om het exemplaar ongeveer 75% vol te vullen, rekening houden met buffers. U kunt deze formule gebruiken: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Als u bijvoorbeeld benchmarkt op een X3-exemplaar dat is geoptimaliseerd voor rekenkracht, met een sleutelgrootte van 1024 byte, zoals eerder wordt weergegeven, betekent {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)dit. Het resultaat is gelijk aan ongeveer 1.699.396 sleutels.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 --clients=50 --threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 --data-size=1024 --tls --cluster-mode

Doorvoer testen: met deze opdracht worden GET-aanvragen met pijplijn getest met 1k-nettolading. Gebruik deze opdracht om te testen hoeveel leesdoorvoer u van uw cache-exemplaar verwacht. In dit voorbeeld wordt ervan uitgegaan dat u TLS en het OSS-clusterbeleid gebruikt. De --key-pattern=R:R parameter zorgt ervoor dat sleutels willekeurig worden geopend, waardoor het realisme van de benchmark wordt verhoogd. Deze test wordt vijf minuten uitgevoerd.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 --clients=50 --threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

Voorbeeld van prestatiebenchmarkgegevens

In de onderstaande tabel ziet u de optimale doorvoer die we hebben vastgesteld tijdens het testen van verschillende groottes van Azure Managed Redis-exemplaren met een workload die bestaat uit alleen leesopdrachten en een belasting van 1 KB. De workload is hetzelfde voor alle SKU's, met uitzondering van het aantal verbindingen (dat wil gezegd, verschillende threads en clientaantallen zoals vereist voor memtier_benchmark). Het aantal verbindingen wordt per SKU gekozen om optimaal gebruik te maken van het Azure Managed Redis-exemplaar. We hebben van een IaaS Azure-VM gebruikt memtier_benchmark voor het Azure Managed Redis-eindpunt, waarbij gebruik wordt gemaakt van de memtier-opdrachten die worden weergegeven in de sectie memtier_benchmark voorbeelden . De doorvoernummers zijn alleen voor GET-opdrachten. Normaal gesproken hebben SET-opdrachten een lagere doorvoer. De prestaties in de praktijk variëren op basis van Redis-configuratie en -opdrachten. Deze nummers worden verstrekt als referentiepunt, niet als garantie.

Azure Managed Redis biedt een keuze uit clusterbeleid: Enterprise en OSS. Clusterbeleid voor ondernemingen is een eenvoudigere configuratie waarvoor de client geen ondersteuning biedt voor clustering. OSS-clusterbeleid maakt daarentegen gebruik van het Redis-clusterprotocol ter ondersteuning van een hogere doorvoer. In de meeste gevallen wordt u aangeraden OSS-clusterbeleid te gebruiken, met name wanneer u hoge prestaties nodig hebt. Zie Clustering voor meer informatie.

De volgende tabel bevat het aantal verbindingen in termen van het aantal threads voor memtier_benchmark en het aantal clients dat is gebruikt om de doorvoercapaciteit te berekenen. Zoals hierboven vermeld, kan het wijzigen van het aantal verbindingen leiden tot verschillende prestaties.

Volgende stappen

• Ontwikkeling
• Azure Cache voor Redis veelgestelde vragen over ontwikkeling
• Failover en toepassing van een patch voor Azure Cache voor Redis