Dela via

Prestandatest

  • Artikel

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

  1. Installera öppen källkod Redis-server på en virtuell klientdator (VM) som du kan använda för testning. Redis-benchmark-verktyget är inbyggt i öppen källkod Redis-distributionen. Följ Redis-dokumentationen för anvisningar om hur du installerar öppen källkod avbildningen.

  2. Den virtuella klientdatorn som används för testning bör finnas i samma region som din Azure Cache for Redis-instans.

  3. Kontrollera att den virtuella klientdatorn som du använder har minst lika mycket beräkning och bandbredd som cacheinstansen som testas.

  4. 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.

  5. Om du använder TLS/SSL på cacheinstansen måste du lägga till parametern --tls i redis-benchmark-kommandot eller använda en proxy som stunnel.

  6. Redis-benchmark använder port 6379 som standard. Använd parametern -p fö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).

  7. Om du använder en Azure Cache for Redis-instans som använder klustring måste du lägga till parametern i --cluster kommandot redis-benchmark . Cacheminnen på företagsnivå som använder klustring kan behandlas som icke-illustrerade cacheminnen och behöver inte den här inställningen.

  8. Starta redis-benchmark frå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å öppen källkod Redis, 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 -r fö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.

  • 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 och memtier-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.

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.

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

Redis-riktmärken på standardnivå

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

Redis-riktmärken på Premium-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)
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 . 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 i partitioneringskonfigurationen. 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

Nästa steg