Delen via

Prestatietests met Azure Managed Redis (preview)

  • Artikel

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

Notitie

In dit voorbeeld ziet u benchmarking op een X3-exemplaar dat is geoptimaliseerd voor compute met behulp van het OSS-clusterbeleid en TLS.

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

Notitie

In dit voorbeeld worden de --tls, --tls-skip-verifyen --cluster-mode vlaggen gebruikt. U hebt deze niet nodig als u Azure Managed Redis gebruikt in de niet-TLS-modus of als u respectievelijk het enterprise-clusterbeleid gebruikt.

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 volgende tabellen ziet u de maximale doorvoerwaarden die zijn waargenomen tijdens het testen van verschillende grootten van Azure Managed Redis-exemplaren. 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.

Let op

Deze waarden worden niet gegarandeerd en er is geen SLA voor deze getallen. We raden u ten zeerste aan om uw eigen prestatietests uit te voeren om de juiste cachegrootte voor uw toepassing te bepalen. Deze aantallen kunnen veranderen omdat we regelmatig nieuwere resultaten plaatsen.

Belangrijk

Microsoft werkt regelmatig de onderliggende VM bij die wordt gebruikt in cache-exemplaren. Hierdoor kunnen de prestatiekenmerken worden gewijzigd van cache naar cache en van regio naar regio. De voorbeeldwaarden voor benchmarking op deze pagina weerspiegelen oudere cachehardware van de generatie in één regio. U ziet mogelijk betere of andere resultaten in de praktijk, met name met netwerkbandbreedte.

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. Zie Clustering voor meer informatie.

Benchmarks voor beide clusterbeleidsregels worden weergegeven in de volgende tabellen. Voor de oss-clusterbeleidstabel zijn er twee benchmarkconfiguraties beschikbaar:

  • 300 verbindingen (50 clients en 6 threads)
  • 2500 verbindingen (50 clients en 50 threads)

De tweede benchmarks worden geleverd omdat 300 verbindingen niet voldoende zijn om de prestaties van de grotere cache-exemplaren volledig te demonstreren.

Hieronder ziet u de doorvoer in GET-bewerkingen per seconde op 1 kB-nettolading voor AMR-exemplaren, samen met het aantal clientverbindingen dat wordt gebruikt voor benchmarking. Alle getallen zijn berekend voor WMV-exemplaren met SSL-verbindingen en de netwerkbandbreedte wordt vastgelegd in Mbps.

OSS-clusterbeleid

Grootte in GB vCPU/Network BW/Geoptimaliseerd voor geheugen vCPU/Network BW/Balanced vCPU/Network BW/Compute geoptimaliseerd
1 - 2/5,000/103,500 -
3 - 2/2,000/104,500 4/10,000/221,100
6 - 2/2,000/106,500 4/10,000/210,850
12 2/2,000/106,000 4/4,000/223,900 8/12,500/499,900
24 4/4,000/227,800 8/8,000/495,300 16/12,500/485,920
60 8/8,000/496,000 16/10,000/476,500 32/16,000/454,200
120 16/10,000/476,200 32/16,000/462,200 64/28,000/463,800

Clusterbeleid onderneming

Grootte in GB vCPU/Network BW/Geoptimaliseerd voor geheugen vCPU/Network BW/Balanced vCPU/Network BW/Compute geoptimaliseerd
1 - 2/5,000/56,900 -
3 - 2/2,000/56,900 4/10,000/118,900
6 - 2/2,000/59,200 4/10,000/111,950
12 2/2,000/55,800 4/4,000/118,500 8/12,500/206,500
24 4/4,000/122,000 8/8,000/205,500 16/12,500/294,700
60 8/8,000/208,100 16/10,000/293,400 32/16,000/441,400
120 16/10,000/285,600 32/16,000/451,700 64/28,000/516,200