Share via

Prestatietesten

  • 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 is gericht op redis-benchmark.

Het hulpprogramma redis-benchmark gebruiken

  1. Installeer de open source Redis-server op een client-VM die u kunt gebruiken voor testen. Het redis-benchmarkhulpprogramma is ingebouwd in de open source Redis-distributie. Volg de Redis-documentatie voor instructies over het installeren van de opensource-installatiekopie.

  2. De client-VM die wordt gebruikt voor het testen, moet zich in dezelfde regio bevinden als uw Azure Cache voor Redis-exemplaar.

  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 firewallinstellingen om ervoor te zorgen dat de client-VM toegang heeft tot uw Azure Cache voor Redis-exemplaar.

  5. Als u TLS/SSL op uw cache-exemplaar gebruikt, moet u de parameter toevoegen aan de --tls redis-benchmark-opdracht of een proxy zoals stunnel gebruiken.

  6. Redis-benchmark gebruikt standaard poort 6379. Gebruik de -p parameter om deze instelling te overschrijven. U moet dit doen -p, als u de SSL/TLS (poort 6380) gebruikt of de Enterprise-laag (poort 10000) gebruikt.

  7. Als u een Azure Cache voor Redis exemplaar gebruikt dat gebruikmaakt van clustering, moet u de --cluster parameter toevoegen aan uw redis-benchmark opdracht. Caches in enterprise-lagen die gebruikmaken van het clusteringbeleid voor ondernemingen, kunnen worden behandeld als niet-geclusterde caches en hebben deze instelling niet nodig.

  8. Start redis-benchmark vanuit de CLI of shell van de VIRTUELE machine. Zie de redis-benchmark-documentatie en de secties met redis-benchmark-voorbeelden voor instructies over het configureren en uitvoeren van het hulpprogramma.

Aanbevelingen voor benchmarking

  • Het is belangrijk om niet alleen de prestaties van uw cache onder stabiele toestand te testen. Test ook onder failovervoorwaarden en meet de CPU/serverbelasting in uw cache gedurende die tijd. U kunt een failover starten door het primaire knooppunt opnieuw op te starten. Door te testen onder failovervoorwaarden kunt u de doorvoer en latentie van uw toepassing zien tijdens failovervoorwaarden. Failover kan optreden tijdens updates of tijdens een niet-geplande gebeurtenis. Idealiter wilt u geen piek van CPU/serverbelasting zien tot meer dan 80% zelfs tijdens een failover, omdat dit van invloed kan zijn op de prestaties.

  • Overweeg het gebruik van Enterprise- en Premium-laag Azure Cache voor Redis exemplaren. Deze cachegrootten hebben een betere netwerklatentie en doorvoer omdat ze worden uitgevoerd op betere hardware.

  • De Enterprise-laag heeft over het algemeen de beste prestaties, omdat Redis Enterprise het kernproces van Redis toestaat om meerdere vCPU's te gebruiken. Lagen op basis van open source Redis, zoals Standard en Premium, kunnen slechts één vCPU gebruiken voor het Redis-proces per shard.

  • Benchmarking van de Enterprise Flash-laag 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 een enterprise-laagexemplaren, maar de sleutels op de NVMe-flashschijf zijn langzamer. Omdat de Enterprise Flash-laag 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. Overweeg het gebruik van de -r parameter om te randomiseren welke sleutels worden geopend.

  • Het gebruik van TLS/SSL vermindert de doorvoerprestaties, wat duidelijk te zien is in het voorbeeld van benchmarkinggegevens in de volgende tabellen.

  • Hoewel een Redis-server één thread heeft, verbetert het omhoog schalen de doorvoerprestaties. Systeemprocessen kunnen gebruikmaken van de extra vCPU's in plaats van de vCPU te delen die wordt gebruikt door het Redis-proces. Omhoog schalen is vooral handig voor de Enterprise- en Enterprise Flash-lagen, omdat Redis Enterprise niet beperkt is tot één thread. Zie best practices voor enterprise-lagen voor meer informatie.

  • In de Premium-laag wordt uitschalen, clusteren, doorgaans aanbevolen voordat u omhoog schaalt. Met clustering kan Redis-server meer vCPU's gebruiken door gegevens te sharden. In dit geval moet de doorvoer ongeveer lineair toenemen bij het toevoegen van shards.

Voorbeelden van Redis-benchmark

Installatie vooraf testen: bereid het cache-exemplaar voor met gegevens die nodig zijn voor de latentie- en doorvoertests:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Latentie testen: GET-aanvragen testen met behulp van een nettolading van 1.000:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Doorvoer testen: GET-aanvragen met pijplijn met 1k-nettolading:

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

De doorvoer van een Cache in de Basic-, Standard- of Premium-laag testen met TLS: Get-aanvragen met pijplijn met 1k-nettolading:

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Doorvoer van een Enterprise- of Enterprise Flash-cache testen zonder TLS met behulp van OSS-clustermodus: Get-aanvragen met pijplijn met 1k-nettolading:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

Voorbeeld van prestatiebenchmarkgegevens

In de volgende tabellen ziet u de maximale doorvoerwaarden die zijn waargenomen tijdens het testen van verschillende grootten van Standard-, Premium-, Enterprise- en Enterprise Flash-caches. We hebben een IaaS Azure-VM gebruikt redis-benchmark op basis van het Azure Cache voor Redis-eindpunt. De doorvoernummers zijn alleen voor GET-opdrachten. Normaal gesproken hebben SET-opdrachten een lagere doorvoer. Deze getallen zijn geoptimaliseerd voor doorvoer. De werkelijke doorvoer onder acceptabele latentievoorwaarden kan lager zijn.

De volgende configuratie is gebruikt om doorvoer te benchmarken voor de Basic-, Standard- en Premium-lagen:

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

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.

Standaardlaag

Exemplaar Tekengrootte vCPU's Verwachte netwerkbandbreedte (Mbps) GET-aanvragen per seconde zonder SSL (grootte van 1 kB-waarde) GET-aanvragen per seconde met SSL (grootte van 1 kB-waarde)
C0 250 MB Gedeeld 100 15.000 7500
C1 1 GB 1 500 38,000 20,720
C2 2.5 GB 2 500 41,000 37,000
C3 6 GB 4 1000 100.000 90,000
C4 13 GB 2 500 60.000 55.000
C5 26 GB 4 1.000 102,000 93,000
C6 53 GB 8 2.000 126,000 120.000

Premium-laag

Exemplaar Tekengrootte vCPU's Verwachte netwerkbandbreedte (Mbps) GET-aanvragen per seconde zonder SSL (grootte van 1 kB-waarde) GET-aanvragen per seconde met SSL (grootte van 1 kB-waarde)
P1 6 GB 2 1.500 180,000 172,000
P2 13 GB 4 3.000 350,000 341,000
P3 26 GB 4 3.000 350,000 341,000
P4 53 GB 8 6.000 400,000 373,000
B5 120 GB 32 6.000 400,000 373,000

Belangrijk

P5-exemplaren in de regio's China - oost en China - noord gebruiken 20 kernen, niet 32 kernen.

Enterprise & Enterprise Flash-lagen

De Enterprise- en Enterprise Flash-lagen bieden 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 hogere doorvoer. In de meeste gevallen wordt u aangeraden OSS-clusterbeleid te gebruiken. Zie Clustering in Enterprise voor meer informatie. Benchmarks voor beide clusterbeleidsregels worden weergegeven in de volgende tabellen.

De volgende configuratie is gebruikt om de doorvoer te benchmarken voor de Enterprise- en Enterprise-flashlagen:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32

Notitie

Deze configuratie is bijna identiek aan de configuratie die wordt gebruikt om de Basic-, Standard- en Premium-lagen te benchmarken. De vorige configuratie maakte echter niet volledig gebruik van de grotere rekenprestaties van de Enterprise-lagen. Er zijn extra aanvragen en threads aan deze configuratie toegevoegd om de volledige prestaties te demonstreren.

Clusterbeleid onderneming

Exemplaar Tekengrootte vCPU's Verwachte netwerkbandbreedte (Mbps) GET-aanvragen per seconde zonder SSL (grootte van 1 kB-waarde) GET-aanvragen per seconde met SSL (grootte van 1 kB-waarde)
E10 12 GB 4 4000 300,000 207,000
E20 25 GB 4 4000 680,000 480,000
E50 50 GB 8 8,000 1,200,000 900,000
E100 100 GB 16 10,000 1,700,000 1,650,000
F300 384 GB 8 3,200 500,000 390,000
F700 715 GB 16 6,400 500,000 370,000
F1500 1455 GB 32 12,800 530,000 390,000

OSS-clusterbeleid

Exemplaar Tekengrootte vCPU's Verwachte netwerkbandbreedte (Mbps) GET-aanvragen per seconde zonder SSL (grootte van 1 kB-waarde) GET-aanvragen per seconde met SSL (grootte van 1 kB-waarde)
E10 12 GB 4 4000 1,400,000 1.000.000
E20 25 GB 4 4000 1,200,000 900,000
E50 50 GB 8 8,000 2,300,000 1,700,000
E100 100 GB 16 10,000 3,000,000 2,500,000
F300 384 GB 8 3,200 1,500,000 1,200,000
F700 715 GB 16 6,400 1,600,000 1,200,000
F1500 1455 GB 32 12,800 1,600,000 1,110,000

Enterprise & Enterprise Flash-lagen - uitgeschaald

Naast omhoog schalen door naar grotere cachegrootte te gaan, kunt u de prestaties verbeteren door uit te schalen. In de Enterprise-lagen wordt uitschalen de capaciteit van het cache-exemplaar verhoogd. Een cache-exemplaar heeft standaard een capaciteit van twee betekenissend een primair en replicaknooppunt. Een Enterprise-cache-exemplaar met een capaciteit van vier geeft aan dat het exemplaar is uitgeschaald met een factor van twee. Uitschalen biedt toegang tot meer geheugen en vCPU's. Details over het aantal vCPU's dat wordt gebruikt door het Redis-kernproces voor elke cachegrootte en capaciteit vindt u op de pagina met aanbevolen procedures voor enterprise-lagen. Uitschalen is het meest effectief wanneer u het OSS-clusterbeleid gebruikt.

In de volgende tabellen ziet u de GET-aanvragen per seconde op verschillende capaciteiten, met behulp van SSL en een grootte van 1 kB-waarden.

Uitschalen - Enterprise-clusterbeleid

Exemplaar Capaciteit 2 Capaciteit 4 Capaciteit 6
E10 200.000 830,000 930,000
E20 480,000 710,000 950,000
E50 900,000 1,110,000 1,200,000
E100 1,600,000 1,120,000 1,200,000
Exemplaar Capaciteit 3 Capaciteit 9
F300 390,000 640,000
F700 370,000 610,000
F1500 390,000 670,000

Uitschalen - OSS-clusterbeleid

Exemplaar Capaciteit 2 Capaciteit 4 Capaciteit 6
E10 1.000.000 1,900,000 2,500,000
E20 900,000 1,700,000 2,300,000
E50 1,700,000 3,000,000 3,900,000
E100 2,500,000 4,400,000 4,900,000
Exemplaar Capaciteit 3 Capaciteit 9
F300 1,200,000 2,600,000
F700 1,200,000 2,600,000
F1500 1,100,000 2,800,000

Volgende stappen