Testování výkonu s využitím Azure Managed Redis (Preview)
Testování výkonu instance Redis může být složitá úloha. Výkon instance Redis se může lišit v závislosti na parametrech, jako je počet klientů, velikost datových hodnot a to, jestli se používá kanálování. Může také dojít k kompromisu mezi optimalizací propustnosti nebo latencí.
Naštěstí existuje několik nástrojů, které usnadňují srovnávací testy Redis. Mezi nejoblíbenější nástroje patří redis-benchmark a memtier-benchmark. Tento článek se zaměřuje na memtier_benchmark, často označovaný jako memtier.
Jak používat nástroj memtier_benchmark
Nainstalujte memtier na klientské virtuální počítače, které můžete použít k testování. Pokyny k instalaci opensourcové image najdete v dokumentaci Memtier.
Klientský virtuální počítač používaný k testování by měl být ve stejné oblasti jako vaše instance Azure Managed Redis (AMR).
Ujistěte se, že má klientský virtuální počítač, který používáte , alespoň tolik výpočetních prostředků a šířku pásma , jak se testuje instance mezipaměti.
Nakonfigurujte izolaci sítě a nastavení brány firewall virtuálního počítače, abyste měli jistotu, že klientský virtuální počítač bude mít přístup k vaší instanci Azure Managed Redis.
Pokud v instanci mezipaměti používáte protokol TLS/SSL, musíte do příkazu memtier_benchmark přidat
--tlsparametry a--tls-skip-verifyparametry.memtier_benchmarkve výchozím nastavení používá port 6379.-p 10000K přepsání tohoto nastavení použijte parametr, protože AMR místo toho používá port 10000.Pro všechny instance Azure Managed Redis pomocí zásad clusteru operačního systému musíte do příkazu memtier přidat
--cluster-modeparametr. Instance AMR používající zásady podnikového clusteru se dají považovat za neclusterované mezipaměti a nepotřebují toto nastavení.Spusťte
memtier_benchmarkz rozhraní příkazového řádku nebo prostředí virtuálního počítače. Pokyny ke konfiguraci a spuštění nástroje najdete v dokumentaci Memtier.
Doporučení pro srovnávací testy
Pokud nemáte požadovaný výkon, zkuste vertikálně navýšit kapacitu na pokročilejší úroveň. Vyvážená úroveň má obvykle dvakrát tolik virtuálních procesorů jako úroveň Optimalizováno pro paměť a úroveň Optimalizovaná pro výpočty má obvykle dvakrát tolik virtuálních procesorů, jako je vyvážená úroveň. Vzhledem k tomu, že Azure Managed Redis je založený na Redis Enterprise, a ne v komunitě Redis, dokáže základní proces Redis využívat více virtuálních procesorů. V důsledku toho mají instance s více virtuálními procesory výrazně lepší výkon propustnosti.
Vertikální navýšení kapacity na větší velikost paměti také zvyšuje počet virtuálních procesorů, což zvyšuje výkon. Vertikální navýšení kapacity na větší velikost paměti je ale obvykle méně efektivní než použití výkonnější vrstvy. Podrobné rozpisy virtuálních procesorů dostupných pro každou velikost a úroveň najdete na první pohled na úrovně a úrovně.
Srovnávací testy úrovně Optimalizované pro Flash můžou být obtížné, protože některé klíče jsou uložené na DRAM, zatímco některé jsou uložené na flash disku NVMe. Klíče na DRAM se testují téměř stejně rychle jako jiné instance Azure Managed Redis, ale klíče na disku NVMe flash jsou pomalejší. Vzhledem k tomu, že úroveň Optimalizovaná pro Flash inteligentně umístí nejpoužívanější klíče do DRAM, ujistěte se, že konfigurace srovnávacího testu odpovídá skutečnému využití, které očekáváte.
Použití protokolu TLS/SSL snižuje výkon propustnosti, ale důrazně se doporučuje jako osvědčený postup v produkčním prostředí.
Před srovnávacím testem je důležité nejprve vyplnit instanci Redis daty. Srovnávací testy v prázdné mezipaměti vytvářejí mnohem lepší výsledky, než byste viděli v praxi.
Použitý počet připojení má významný vliv na srovnávací test. Použití příliš velkého počtu připojení začne snižovat výkon mezipaměti. Použití příliš málo připojení neukazuje úplný výkon mezipaměti. Doporučujeme nakonfigurovat počet připojení na základě vašich skutečných potřeb aplikace. Celkový počet připojení určíte vynásobením počtu klientů počtem vláken.
Konfigurace kanálu má významný vliv na testování výkonu. Pokud nastavíte nastavení kanálu na větší, zobrazí se větší propustnost, ale horší latence. Další informace najdete v tématu pipelining.
příklady memtier_benchmark
Poznámka:
Tento příklad ukazuje srovnávací testy u instance X3 optimalizované pro výpočty pomocí zásad clusteru operačního systému a protokolu TLS.
Předtestování nastavení: Připravte instanci mezipaměti s daty požadovanými pro testování. Načtení instance s daty zajišťuje, aby výsledky přesněji odrážely reálné podmínky. Parametr {number-of-keys} by měl být určen velikostí instance AMR a velikostí každého klíče. Dobrým pravidlem je vyplnit instanci přibližně 75 % plnou, která se počítá s vyrovnávacími paměťmi. Můžete použít tento vzorec: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Pokud například testujete instanci X3 optimalizovanou pro výpočty s použitím velikosti klíčů 1 024 bajtů, jak je znázorněno výše, znamená {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)to . Výsledek se rovná přibližně 1 699 396 klíčům.
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
Poznámka:
V tomto příkladu se používá příznak --tls, --tls-skip-verifya --cluster-mode příznaky. Pokud používáte Azure Managed Redis v režimu jiného než TLS, nebo pokud používáte zásady podnikového clusteru, nemusíte je potřebovat.
Test propustnosti: Tento příkaz testuje požadavky GET s datovou částí 1k. Tento příkaz použijte k otestování očekávané propustnosti čtení z instance mezipaměti. Tento příklad předpokládá, že používáte protokol TLS a zásady clusteru operačního systému. Parametr --key-pattern=R:R zajišťuje náhodný přístup ke klíčům, což zvyšuje realismus srovnávacího testu. Tento test běží pět minut.
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
Příklad dat srovnávacího testu výkonu
Následující tabulky ukazují hodnoty maximální propustnosti, které byly pozorovány při testování různých velikostí instancí Azure Managed Redis. Použili memtier_benchmark jsme z virtuálního počítače Azure IaaS vůči koncovému bodu Azure Managed Redis s využitím příkazů memtier zobrazených v části memtier_benchmark příklady . Čísla propustnosti jsou určená jenom pro příkazy GET. Příkazy SET mají obvykle nižší propustnost. Skutečný výkon se liší v závislosti na konfiguraci a příkazech Redis. Tato čísla jsou poskytována jako referenční bod, nikoli záruka.
Upozornění
Tyto hodnoty nejsou zaručené a pro tato čísla neexistuje žádná smlouva SLA. Důrazně doporučujeme provést vlastní testování výkonu, abyste určili správnou velikost mezipaměti pro vaši aplikaci. Tyto hodnoty se můžou změnit, protože pravidelně zveřejňujeme nové výsledky.
Důležité
Microsoft pravidelně aktualizuje základní virtuální počítač používaný v instancích mezipaměti. To může změnit charakteristiky výkonu z mezipaměti do mezipaměti a z oblasti do oblasti. Ukázkové hodnoty srovnávacích testů na této stránce odrážejí hardware mezipaměti starší generace v jedné oblasti. V praxi můžete vidět lepší nebo odlišné výsledky, zejména s šířkou pásma sítě.
Azure Managed Redis nabízí volbu zásad clusteru: Enterprise a OSS. Zásady podnikového clusteru jsou jednodušší konfigurace, která nevyžaduje, aby klient podporoval clustering. Zásady clusteru OSS na druhou stranu používají protokol clusteru Redis k podpoře vyšší propustnosti. Ve většině případů doporučujeme používat zásady clusteru operačního systému. Další informace najdete v tématu Clustering.
Srovnávací testy pro obě zásady clusteru jsou uvedené v následujících tabulkách. Pro tabulku zásad clusteru operačního systému jsou k dispozici dvě konfigurace srovnávacích testů:
- 300 připojení (50 klientů a 6 vláken)
- 2 500 připojení (50 klientů a 50 vláken)
Druhé srovnávací testy jsou k dispozici, protože 300 připojení nestačí k úplnému předvedení výkonu větších instancí mezipaměti.
Následují propustnost operací GET za sekundu při 1 kB datových částí instancí AMR a počtu klientských připojení používaných pro srovnávací testy. Všechna čísla byla vypočtena pro instance AMR s připojeními SSL a šířka pásma sítě se zaznamenává v Mb/s.
Zásady clusteru operačního systému
| Velikost v GB | vCPU/Network BW/Memory Optimized | vCPU/Network BW/Balanced | vCPU/Network BW/Compute Optimized |
|---|---|---|---|
| 0 | - | 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 |
Zásady podnikového clusteru
| Velikost v GB | vCPU/Network BW/Memory Optimized | vCPU/Network BW/Balanced | vCPU/Network BW/Compute Optimized |
|---|---|---|---|
| 0 | - | 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 |