Dela via

Prestandatestning med Azure Managed Redis

  • Gäller för: ✅ Azure Managed Redis

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å memtier_benchmark, som ofta kallas memtier.

Så här använder du verktyget memtier_benchmark

  1. Installera memtier på en virtuell klientdator (VM) som du kan använda för testning. Följ Memtier-dokumentationen för anvisningar om hur du installerar öppen källkod avbildningen.

  2. Den virtuella klientdator (VM) som används för testning bör finnas i samma region som din Azure Managed Redis-instans (AMR).

  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 VM-brandväggsinställningarna för att säkerställa att den virtuella klientdatorn kan komma åt din Azure Managed Redis-instans.

  5. Om du använder TLS/SSL på cacheinstansen måste du lägga till parametrarna --tls och --tls-skip-verify i kommandot memtier_benchmark.

  6. memtier_benchmark använder port 6379 som standard. Använd parametern -p 10000 för att åsidosätta den här inställningen eftersom AMR använder port 10000 i stället.

  7. För alla Azure Managed Redis-instanser som använder OSS-klusterprincipen måste du lägga till parametern --cluster-mode i ditt memtier-kommando. AMR-instanser som använder enterprise-klusterprincipen kan behandlas som icke-illustrerade cacheminnen och behöver inte den här inställningen.

  8. Starta memtier_benchmark från CLI eller gränssnittet för den virtuella datorn. Anvisningar om hur du konfigurerar och kör verktyget finns i Memtier-dokumentationen.

Rekommendationer för benchmarking

  • Om du inte får den prestanda du behöver kan du prova att skala upp till en mer avancerad nivå. Den balanserade nivån har vanligtvis dubbelt så många vCPU:er som nivån Minnesoptimerad, och nivån Beräkningsoptimerad har vanligtvis dubbelt så många vCPU:er som den balanserade nivån. Eftersom Azure Managed Redis bygger på Redis Enterprise i stället för communityn Redis kan Redis-kärnprocessen använda flera virtuella processorer. Därför har instanser med fler vCPU:er betydligt bättre dataflödesprestanda.

  • Att skala upp till större minnesstorlekar ger också fler vCPU:er, vilket ökar prestandan. Men att skala upp till större minnesstorlekar är vanligtvis mindre effektivt än att använda en mer högpresterande nivå. Mer information finns i Nivåer och SKU:er för en detaljerad uppdelning av de vCPU:er som är tillgängliga för varje storlek och nivå.

  • Det kan vara svårt att jämföra Nivån Flash-optimerad eftersom vissa nycklar lagras på DRAM medan vissa lagras på en NVMe-flashdisk. Nycklarna på DRAM-benchmark nästan lika snabbt som andra Azure Managed Redis-instanser, men nycklarna på NVMe-flashdisken är långsammare. Eftersom Flash Optimized-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.

  • Användning av TLS/SSL minskar dataflödesprestandan, men rekommenderas starkt som bästa praxis för produktion.

  • Det är viktigt att först fylla Redis-instansen med data före benchmarking. Benchmarking på en tom cache ger mycket bättre resultat än du skulle se i praktiken.

  • Antalet anslutningar som används har en betydande inverkan på riktmärket. Användning av för många anslutningar börjar försämra cachens prestanda. Att använda för få anslutningar visar inte cachens fullständiga prestanda. Vi rekommenderar att du konfigurerar antalet anslutningar baserat på dina faktiska programbehov. Du avgör det totala antalet anslutningar genom att multiplicera antalet klienter med antalet trådar.

  • Pipelinekonfigurationen har en betydande effekt på prestandatestningen. Om du anger att pipelineinställningen ska vara större ser du mer dataflöde, men sämre svarstid. Mer information finns i pipelining.

memtier_benchmark exempel

Anmärkning

Det här exemplet visar benchmarking på en Beräkningsoptimerad X3-instans med hjälp av OSS-klusterprincipen och TLS.

Konfiguration före test: Förbered cacheinstansen med data som krävs för testningen. Genom att läsa in instansen med data ser du till att resultatet bättre återspeglar verkliga förhållanden. Parametern {number-of-keys} bör bestämmas av storleken på din AMR-instans och storleken på varje nyckel. En bra tumregel är att fylla instansen ungefär 75 % full, vilket motsvarar buffertar. Du kan använda den här formeln: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Om du till exempel använder benchmarking på en Beräkningsoptimerad X3-instans med nyckelstorlekar på 1 024 byte, som du visade tidigare, innebär {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)det . Resultatet motsvarar cirka 1 699 396 nycklar.

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

Anmärkning

I det här exemplet används flaggorna --tls, --tls-skip-verifyoch --cluster-mode . Du behöver inte dessa om du använder Azure Managed Redis i icke-TLS-läge eller om du använder enterprise-klusterprincipen.

Så här testar du dataflödet: Det här kommandot testar pipelines för GET-begäranden med 1k nyttolast. Använd det här kommandot för att testa hur mycket läsdataflöde du kan förvänta dig från cacheinstansen. Det här exemplet förutsätter att du använder TLS och OSS-klusterprincipen. Parametern --key-pattern=R:R säkerställer att nycklar används slumpmässigt, vilket ökar prestandamåttets realism. Det här testet körs i fem minuter.

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

Exempel på prestandamåttdata

Tabellen nedan visar optimalt dataflöde som vi observerade när vi testade olika storlekar på Azure Managed Redis-instanser med en arbetsbelastning med alla läskommandon och 1 KB-nyttolast. Arbetsbelastningen är densamma för alla SKU:er, förutom antalet anslutningar (det vill: olika tråd- och klientantal som krävs av memtier_benchmark). Antalet anslutningar väljs per SKU för att utnyttja Azure Managed Redis-instansen optimalt. Vi använde memtier_benchmark från en virtuell IaaS Azure-dator mot Azure Managed Redis-slutpunkten och använde de memtier-kommandon som visas i avsnittet memtier_benchmark exempel . Dataflödesnumren är endast för GET-kommandon. Normalt har SET-kommandon ett lägre dataflöde. Verkliga prestanda varierar beroende på Redis-konfiguration och kommandon. Dessa siffror tillhandahålls som referenspunkt, inte som en garanti.

Försiktighet

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. Prestanda kan variera av olika orsaker som olika anslutningsantal, nyttolaststorlek, kommandon som körs osv.

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 en viss generations cachemaskinvara i en enda region. Du kan se olika resultat i praktiken, särskilt med nätverksbandbredd.

Azure Managed Redis 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öde. Vi rekommenderar att du använder OSS-klusterprincip i de flesta fall, särskilt när du behöver höga prestanda. Mer information finns i Klustring.

Storlek i GB Minnesoptimerad Balanserad Beräkningsoptimerad
0,5 - 120 000 -
1 - 120 000 -
3 - 230,000 480 000
6 - 230,000 480 000
12 230,000 480 000 810,000
24 480 000 810,000 1,600,000
60 810,000 1,500,000 2,000,000
120 1,500,000 2,000,000 2,900,000

I följande tabell visas antalet anslutningar i termer av memtier_benchmark trådantal, klientantal som användes för att generera genomströmningssiffrorna. Som nämnts ovan kan en ändring av antalet anslutningar resultera i varierande prestanda.

Storlek i GB Klienter/trådar/anslutningsantal för minnesoptimerade inställningar Klienter/trådar/antal anslutningar för balansering Klienter/trådar/antal anslutningar för beräkningsoptimerad
0,5 - 10/4/40 -
1 - 10/4/40 -
3 - 10/4/40 10/8/80
6 - 10/4/40 10/8/80
12 10/4/40 10/8/80 10/16/160
24 10/8/80 10/16/160 20/16/320
60 10/16/160 20/16/320 20/32/640
120 20/16/320 20/32/640 20/64/1280

Nästa steg