Dela via

Prestandatestning med Azure Managed Redis (förhandsversion)

  • 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å 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

Kommentar

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

Kommentar

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

Följande tabeller visar de maximala dataflödesvärden som observerades vid testning av olika storlekar på Azure Managed Redis-instanser. 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.

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, 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. Mer information finns i Klustring.

Benchmarks för båda klusterprinciperna visas i följande tabeller. För OSS-klusterprinciptabellen tillhandahålls två benchmarking-konfigurationer:

  • 300 anslutningar (50 klienter och 6 trådar)
  • 2 500 anslutningar (50 klienter och 50 trådar)

Det andra riktmärkena tillhandahålls eftersom 300 anslutningar inte räcker för att helt demonstrera prestanda för de större cacheinstanserna.

Följande är dataflöde i GET-åtgärder per sekund på 1 kB nyttolast för AMR-instanser längs antalet klientanslutningar som används för benchmarking. Alla tal beräknades för AMR-instanser med SSL-anslutningar och nätverksbandbredden registreras i Mbit/s.

OSS-klusterprincip

Storlek i GB vCPU/Network BW/Memory Optimized vCPU/Network BW/Balanced vCPU/Network BW/Compute Optimized
1 - 2/5,000/103,500 -
3 - 2/2,000/104,500 4/10,000/221,100
6 - 2/2,000/106,500 4/10,000/210,850
12 2/2,000/106,000 4/4,000/223,900 8/12,500/499,900
24 4/4,000/227,800 8/8,000/495,300 16/12,500/485,920
60 8/8,000/496,000 16/10,000/476,500 32/16,000/454,200
120 16/10,000/476,200 32/16,000/462,200 64/28,000/463,800

Princip för företagskluster

Storlek i GB vCPU/Network BW/Memory Optimized vCPU/Network BW/Balanced vCPU/Network BW/Compute Optimized
1 - 2/5,000/56,900 -
3 - 2/2,000/56,900 4/10,000/118,900
6 - 2/2,000/59,200 4/10,000/111,950
12 2/2,000/55,800 4/4,000/118,500 8/12,500/206,500
24 4/4,000/122,000 8/8,000/205,500 16/12,500/294,700
60 8/8,000/208,100 16/10,000/293,400 32/16,000/441,400
120 16/10,000/285,600 32/16,000/451,700 64/28,000/516,200