Prestatietesten
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
Installeer open source Redis-server op een virtuele clientmachine (VM's) 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.
De client-VM die wordt gebruikt voor het testen, moet zich in dezelfde regio bevinden als uw Azure Cache voor Redis-exemplaar.
Zorg ervoor dat de client-VM die u gebruikt ten minste evenveel rekenkracht en bandbreedte heeft als het cache-exemplaar dat wordt getest.
Configureer uw netwerkisolatie en firewallinstellingen om ervoor te zorgen dat de client-VM toegang heeft tot uw Azure Cache voor Redis-exemplaar.
Als u TLS/SSL op uw cache-exemplaar gebruikt, moet u de parameter toevoegen aan de
--tlsredis-benchmark-opdracht of een proxy zoals stunnel gebruiken.Redis-benchmarkgebruikt standaard poort 6379. Gebruik de-pparameter 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.Als u een Azure Cache voor Redis exemplaar gebruikt dat gebruikmaakt van clustering, moet u de
--clusterparameter toevoegen aan uwredis-benchmarkopdracht. Caches in enterprise-lagen die gebruikmaken van het clusteringbeleid voor ondernemingen, kunnen worden behandeld als niet-geclusterde caches en hebben deze instelling niet nodig.Start
redis-benchmarkvanuit 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
-rparameter 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.
In C0 - en C1 Standard-caches, terwijl interne Defender-scans worden uitgevoerd op de VM's, ziet u mogelijk korte pieken in serverbelasting die niet worden veroorzaakt door een toename van cacheaanvragen. U ziet een hogere latentie voor aanvragen terwijl interne Defender-scans een paar keer per dag worden uitgevoerd op deze lagen. Caches op de C0 - en C1-lagen hebben slechts één kern voor multitask, waarbij het werk van het verwerken van interne Defender-scans en Redis-aanvragen wordt verdeeld. U kunt het effect verminderen door te schalen naar een hogere laag met meerdere CPU-kernen, zoals C2.
De grotere cachegrootte op de hogere lagen helpt eventuele latentieproblemen op te lossen. Op C2-niveau hebt u ook ondersteuning voor zo veel als 2000 clientverbindingen.
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 bij 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 |