Prestandatest
Att testa prestanda för en Redis-instans kan vara en komplicerad uppgift. Prestanda för en Redis-instans kan variera beroende på parametrar som antalet klienter, storleken på datavärden och om pipelining används. Det kan också finnas en kompromiss mellan att optimera dataflödet eller svarstiden.
Lyckligtvis finns det flera verktyg för att göra benchmarking Redis enklare. Två av de mest populära verktygen är redis-benchmark och memtier-benchmark. Den här artikeln fokuserar på redis-benchmark.
Så här använder du redis-benchmark-verktyget
Installera Redis-servern med öppen källkod på en virtuell klientdator (VM) som du kan använda för testning. Redis-benchmark-verktyget är inbyggt i Redis-distributionen med öppen källkod. Följ Redis-dokumentationen för anvisningar om hur du installerar avbildningen med öppen källkod.
Den virtuella klientdatorn som används för testning bör finnas i samma region som din Azure Cache for Redis-instans.
Kontrollera att den virtuella klientdatorn som du använder har minst lika mycket beräkning och bandbredd som cacheinstansen som testas.
Konfigurera nätverksisolerings- och brandväggsinställningarna för att säkerställa att den virtuella klientdatorn kan komma åt din Azure Cache for Redis-instans.
Om du använder TLS/SSL på cacheinstansen måste du lägga till parametern
--tlsi redis-benchmark-kommandot eller använda en proxy som stunnel.Redis-benchmarkanvänder port 6379 som standard. Använd parametern-pför att åsidosätta den här inställningen. Du måste använda-p, om du använder SSL/TLS (port 6380) eller använder Enterprise-nivån (port 10000).Om du använder en Azure Cache for Redis-instans som använder klustring måste du lägga till parametern i
--clusterkommandotredis-benchmark. Cacheminnen på företagsnivå med hjälp av enterprise-klustringsprincipen kan behandlas som icke-grupperade cacheminnen och behöver inte den här inställningen.Starta
redis-benchmarkfrån CLI eller gränssnittet för den virtuella datorn. Anvisningar om hur du konfigurerar och kör verktyget finns i redis-benchmark-dokumentationen och redis-benchmark-exemplen.
Rekommendationer för benchmarking
Det är viktigt att inte bara testa cachens prestanda under stabila tillstånd. Testa även under redundansförhållanden och mät cpu-/serverbelastningen i cacheminnet under den tiden. Du kan starta en redundansväxling genom att starta om den primära noden. Genom att testa under redundansförhållanden kan du se programmets dataflöde och svarstid under redundansväxlingen. Redundansväxling kan ske under uppdateringar eller under en oplanerad händelse. Helst vill du inte se cpu-/serverbelastningstoppar till mer än 80 % även under en redundansväxling eftersom det kan påverka prestandan.
Överväg att använda Azure Cache for Redis-instanser på Enterprise- och Premium-nivå. Dessa cachestorlekar har bättre nätverkssvarstid och dataflöde eftersom de körs på bättre maskinvara.
Enterprise-nivån har vanligtvis bästa prestanda eftersom Redis Enterprise tillåter att redis-kärnprocessen använder flera virtuella processorer. Nivåer baserade på Redis med öppen källkod, till exempel Standard och Premium, kan bara använda en vCPU för Redis-processen per shard.
Det kan vara svårt att jämföra Enterprise Flash-nivån eftersom vissa nycklar lagras på DRAM medan vissa lagras på en NVMe-flashdisk. Nycklarna på DRAM-benchmark nästan lika snabbt som en instans på Enterprise-nivå, men nycklarna på NVMe-flashdisken är långsammare. Eftersom Enterprise Flash-nivån intelligent placerar de mest använda nycklarna i DRAM kontrollerar du att benchmark-konfigurationen matchar den faktiska användning du förväntar dig. Överväg att använda parametern
-rför att randomisera vilka nycklar som används.Om du använder TLS/SSL minskar dataflödesprestandan, vilket visas tydligt i exemplet på benchmarking-data i följande tabeller.
Även om en Redis-server är enkeltrådad tenderar uppskalning att förbättra dataflödesprestandan. Systemprocesser kan använda de extra vCPU:er i stället för att dela den vCPU som används av Redis-processen. Att skala upp är särskilt användbart på Enterprise- och Enterprise Flash-nivåerna eftersom Redis Enterprise inte är begränsat till en enda tråd. Mer information finns i Metodtips på företagsnivå.
På Premium-nivån rekommenderas utskalning, klustring, vanligtvis innan du skalar upp. Med klustring kan Redis-servern använda fler vCPU:er genom att partitionera data. Dataflödet bör öka ungefär linjärt när du lägger till shards i det här fallet.
På C0 - och C1 Standard-cacheminnen, medan intern Defender-genomsökning körs på de virtuella datorerna, kan du se korta toppar i serverbelastningen som inte orsakas av en ökning av cachebegäranden. Du ser högre svarstid för begäranden medan interna Defender-genomsökningar körs på dessa nivåer ett par gånger om dagen. Cacheminnen på C0 - och C1-nivåerna har bara en enda kärna till multitask, vilket delar upp arbetet med att hantera interna Defender-genomsökningar och Redis-begäranden. Du kan minska effekten genom att skala till ett erbjudande på högre nivå med flera CPU-kärnor, till exempel C2.
Den ökade cachestorleken på de högre nivåerna hjälper dig att åtgärda eventuella problem med svarstiden. På C2-nivå har du dessutom stöd för så många som 2 000 klientanslutningar.
Redis-benchmark-exempel
Konfiguration före test: Förbered cacheinstansen med data som krävs för svarstids- och dataflödestestning:
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024
Så här testar du svarstiden: Testa GET-begäranden med en nyttolast på 1 000:
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4
Så här testar du dataflödet: Pipeline-GET-begäranden med 1k nyttolast:
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
Så här testar du dataflödet för en cache på Basic-, Standard- eller Premium-nivå med hjälp av TLS: Pipeline-GET-begäranden med 1k nyttolast:
redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --tls
Så här testar du dataflödet för ett Enterprise- eller Enterprise Flash-cacheminne utan TLS med HJÄLP av OSS-klusterläge: Pipeline-GET-begäranden med 1k nyttolast:
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --cluster
Exempel på prestandamåttdata
Följande tabeller visar de maximala dataflödesvärden som observerades vid testning av olika storlekar på Standard-, Premium-, Enterprise- och Enterprise Flash-cacheminnen. Vi använde redis-benchmark från en virtuell IaaS Azure-dator mot Azure Cache for Redis-slutpunkten. Dataflödesnumren är endast för GET-kommandon. Normalt har SET-kommandon ett lägre dataflöde. Dessa tal är optimerade för dataflöde. Verkliga dataflöden under acceptabla svarstider kan vara lägre.
Följande konfiguration användes för att jämföra dataflödet för nivåerna Basic, Standard och Premium:
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
Varning
Dessa värden garanteras inte och det finns inget serviceavtal för dessa tal. Vi rekommenderar starkt att du utför dina egna prestandatester för att fastställa rätt cachestorlek för ditt program. De här siffrorna kan ändras då vi publicerar nyare resultat med jämna mellanrum.
Viktigt!
Microsoft uppdaterar regelbundet den underliggande virtuella datorn som används i cacheinstanser. Detta kan ändra prestandaegenskaperna från cacheminne till cache och från region till region. Exempelvärdena för benchmarking på den här sidan återspeglar äldre generationens cachemaskinvara i en enda region. Du kan se bättre eller olika resultat i praktiken.
Standard-nivå
| Instans | Storlek | vCPU:er | Förväntad nätverksbandbredd (Mbit/s) | GET-begäranden per sekund utan SSL (värdestorlek på 1 kB) | GET-begäranden per sekund med SSL (värdestorlek på 1 kB) |
|---|---|---|---|---|---|
| C0 | 250 MB | Delad | 100 | 15 000 | 7 500 |
| 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 |
Premiumnivå
| Instans | Storlek | vCPU:er | Förväntad nätverksbandbredd (Mbit/s) | GET-begäranden per sekund utan SSL (värdestorlek på 1 kB) | GET-begäranden per sekund med SSL (värdestorlek på 1 kB) |
|---|---|---|---|---|---|
| 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 |
| P5 | 120 GB | 32 | 6 000 | 400,000 | 373,000 |
Viktigt!
P5-instanser i regionerna Kina, östra och Kina, norra använder 20 kärnor, inte 32 kärnor.
Enterprise- och Enterprise Flash-nivåer
Enterprise- och Enterprise Flash-nivåerna erbjuder ett urval av klusterprinciper: Enterprise och OSS. Företagsklusterprincip är en enklare konfiguration som inte kräver att klienten stöder klustring. OSS-klusterprincipen använder å andra sidan Redis-klusterprotokollet för att stödja högre dataflöden. Vi rekommenderar att du använder OSS-klusterprincip i de flesta fall. Mer information finns i Klustring på företag. Benchmarks för båda klusterprinciperna visas i följande tabeller.
Följande konfiguration användes för att jämföra dataflödet för flash-nivåerna Enterprise och Enterprise:
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
Kommentar
Den här konfigurationen är nästan identisk med den som används för att jämföra nivåerna Basic, Standard och Premium. Den tidigare konfigurationen använde dock inte helt den högre beräkningsprestandan för Enterprise-nivåerna. Ytterligare begäranden och trådar har lagts till i den här konfigurationen för att demonstrera fullständig prestanda.
Princip för företagskluster
| Instans | Storlek | vCPU:er | Förväntad nätverksbandbredd (Mbit/s) | GET begäranden per sekund utan SSL (värdestorlek på 1 kB) |
GET begäranden per sekund med SSL (värdestorlek på 1 kB) |
|---|---|---|---|---|---|
| E10 | 12 GB | 4 | 4 000 | 300,000 | 207,000 |
| E20 | 25 GB | 4 | 4 000 | 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-klusterprincip
| Instans | Storlek | vCPU:er | Förväntad nätverksbandbredd (Mbit/s) | GET begäranden per sekund utan SSL (värdestorlek på 1 kB) |
GET begäranden per sekund med SSL (värdestorlek på 1 kB) |
|---|---|---|---|---|---|
| E10 | 12 GB | 4 | 4 000 | 1,400,000 | 1 000 000 |
| E20 | 25 GB | 4 | 4 000 | 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- och Enterprise Flash-nivåer – skalas ut
Förutom att skala upp genom att flytta till större cachestorlek kan du öka prestandan genom att skala ut. På Enterprise-nivåerna kallas utskalning för att öka kapaciteten för cacheinstansen. En cacheinstans har som standard kapacitet på två, vilket innebär en primär nod och repliknod. En Enterprise-cacheinstans med en kapacitet på fyra anger att instansen skalades ut av en faktor på två. Utskalning ger åtkomst till mer minne och virtuella processorer. Information om hur många vCPU:er som används av redis-kärnprocessen vid varje cachestorlek och kapacitet finns på sidan Metodtips för Företagsnivåer. Utskalning är mest effektivt när du använder OSS-klusterprincipen.
I följande tabeller visas GET begäranden per sekund med olika kapaciteter, med hjälp av SSL och en värdestorlek på 1 kB.
Utskalning – Princip för enterprise-kluster
| Instans | Kapacitet 2 | Kapacitet 4 | Kapacitet 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 |
| Instans | Kapacitet 3 | Kapacitet 9 |
|---|---|---|
| F300 | 390,000 | 640,000 |
| F700 | 370,000 | 610,000 |
| F1500 | 390,000 | 670,000 |
Utskalning – OSS-klusterprincip
| Instans | Kapacitet 2 | Kapacitet 4 | Kapacitet 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 |
| Instans | Kapacitet 3 | Kapacitet 9 |
|---|---|---|
| F300 | 1,200,000 | 2,600,000 |
| F700 | 1,200,000 | 2,600,000 |
| F1500 | 1,100,000 | 2,800,000 |