Testování výkonu

  • Článek

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 srovnávací test Redis.

Jak používat nástroj redis-benchmark

  1. Nainstalujte opensourcový server Redis na klientský virtuální počítač, který můžete použít k testování. Nástroj redis-benchmark je integrovaný do opensourcové distribuce Redis. Pokyny k instalaci opensourcové image najdete v dokumentaci k Redisu.

  2. Klientský virtuální počítač použitý k testování by měl být ve stejné oblasti jako vaše instance Azure Cache for Redis.

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

  4. Nakonfigurujte izolaci sítě a nastavení brány firewall , abyste měli jistotu, že klientský virtuální počítač bude mít přístup k vaší instanci Azure Cache for Redis.

  5. Pokud ve své instanci mezipaměti používáte protokol TLS/SSL, musíte do příkazu redis-benchmark přidat --tls parametr nebo použít proxy server, jako jetunnel.

  6. Redis-benchmark ve výchozím nastavení používá port 6379. -p K přepsání tohoto nastavení použijte parametr. -pPokud používáte PROTOKOL SSL/TLS (port 6380) nebo používáte úroveň Enterprise (port 10000).

  7. Pokud používáte instanci Azure Cache for Redis, která používá clustering, musíte do redis-benchmark příkazu přidat --cluster parametr. Mezipaměty podnikové úrovně využívající zásady clusteringu Enterprise se dají považovat za neclusterované mezipaměti a nepotřebují toto nastavení.

  8. Spusťte redis-benchmark z 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 k redis-benchmarku a v částech s příklady redis-benchmarku.

Doporučení pro srovnávací testy

  • Je důležité nejen testovat výkon mezipaměti za podmínek stabilního stavu. Otestujte také za podmínek převzetí služeb při selhání a změřte zatížení procesoru nebo serveru v mezipaměti během této doby. Převzetí služeb při selhání můžete spustit restartováním primárního uzlu. Testování za podmínek převzetí služeb při selhání umožňuje zobrazit propustnost a latenci aplikace během podmínek převzetí služeb při selhání. Převzetí služeb při selhání může proběhnout během aktualizací nebo během neplánované události. V ideálním případě nechcete vidět špičku zatížení procesoru nebo serveru na více než 80 % ani během převzetí služeb při selhání, protože to může ovlivnit výkon.

  • Zvažte použití instancí Azure Cache úrovně Enterprise a Premium pro Redis. Tyto velikosti mezipaměti mají lepší latenci sítě a propustnost, protože běží na lepším hardwaru.

  • Úroveň Enterprise má obecně nejlepší výkon, protože Redis Enterprise umožňuje základnímu procesu Redis využívat více virtuálních procesorů. Vrstvy založené na opensourcovém redisu, jako je Standard a Premium, můžou využívat pouze jeden virtuální procesor pro proces Redis na horizontální oddíl.

  • Srovnávací testy úrovně Enterprise Flash můžou být obtížné, protože některé klíče se ukládají na DRAM, zatímco některé jsou uložené na flash disku NVMe. Klíče na DRAM se testují téměř stejně rychle jako instance podnikové úrovně, ale klíče na disku NVMe flash jsou pomalejší. Vzhledem k tomu, že úroveň Enterprise Flash inteligentně umístí nejčastěji používané klíče do DRAM, ujistěte se, že konfigurace srovnávacího testu odpovídá skutečnému očekávanému využití. Zvažte použití parametru -r k náhodnému přístupu ke klíčům.

  • Použití protokolu TLS/SSL snižuje výkon propustnosti, což je zřejmé v příkladu srovnávacích dat v následujících tabulkách.

  • I když je server Redis s jedním vláknem, vertikální navýšení kapacity má tendenci zvýšit výkon propustnosti. Systémové procesy můžou místo sdílení virtuálního procesoru používaného procesem Redis používat dodatečné virtuální procesory. Vertikální navýšení kapacity je užitečné zejména na úrovních Enterprise a Enterprise Flash, protože Redis Enterprise není omezené na jedno vlákno. Další informace najdete v osvědčených postupech na úrovni Enterprise.

  • Na úrovni Premium se před vertikálním navýšením kapacity obvykle doporučuje horizontální navýšení kapacity clusteringu. Clustering umožňuje serveru Redis používat více virtuálních procesorů horizontálním dělením dat. Propustnost by se měla při přidávání horizontálních oddílů v tomto případě zvyšovat zhruba lineárně.

Příklady srovnávacích testů Redis

Předběžné nastavení testu: Příprava instance mezipaměti s daty požadovanými pro testování latence a propustnosti:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Test latence: Otestujte požadavky GET pomocí datové části 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Testování propustnosti: Požadavky GET s kanálem s datovou částí 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Testování propustnosti mezipaměti úrovně Basic, Standard nebo Premium pomocí protokolu TLS: Požadavky GET s kanálem s datovou částí 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Testování propustnosti mezipaměti Enterprise nebo Enterprise Flash bez protokolu TLS pomocí režimu clusteru OSS: Požadavky GET s kanálem GET s datovou částí 1k:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

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í mezipamětí Standard, Premium, Enterprise a Enterprise Flash. Použili redis-benchmark jsme z virtuálního počítače Azure IaaS pro koncový bod Azure Cache for Redis. Čísla propustnosti jsou určená jenom pro příkazy GET. Příkazy SET mají obvykle nižší propustnost. Tato čísla jsou optimalizovaná pro propustnost. Propustnost reálného světa za přijatelných podmínek latence může být nižší.

Následující konfigurace se použila k srovnávacímu testování propustnosti pro úrovně Basic, Standard a Premium:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

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 se může zobrazit lepší nebo jiné výsledky.

Úroveň Standard

Instance Velikost Počet vCPU Očekávaná šířka pásma sítě (Mb/s) Požadavky GET za sekundu bez SSL (velikost hodnoty 1 kB) Požadavky GET za sekundu s protokolem SSL (velikost hodnoty 1 kB)
C0 250 MB Shared 100 15 000 7 500
S1 1 GB 0 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 1000 102,000 93,000
C6 53 GB 8 2 000 126,000 120 000

Úroveň Premium

Instance Velikost Počet vCPU Očekávaná šířka pásma sítě (Mb/s) Požadavky GET za sekundu bez SSL (velikost hodnoty 1 kB) Požadavky GET za sekundu s protokolem SSL (velikost hodnoty 1 kB)
O1 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

Důležité

Instance P5 v oblastech Čína – východ a Čína – sever používají 20 jader, ne 32 jader.

Úrovně Enterprise a Enterprise Flash

Úrovně Enterprise a Enterprise Flash nabízejí 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 naopak 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 v podniku. Srovnávací testy pro obě zásady clusteru jsou uvedené v následujících tabulkách.

Následující konfigurace se použila k srovnávacímu testování propustnosti pro podnikové a podnikové úrovně flash:

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

Poznámka:

Tato konfigurace je téměř stejná jako ta, která se používá k srovnávacímu testování úrovní Basic, Standard a Premium. Předchozí konfigurace ale plně nevyužila vyšší výpočetní výkon úrovní Enterprise. Do této konfigurace byly přidány další požadavky a vlákna, aby bylo možné demonstrovat úplný výkon.

Zásady podnikového clusteru

Instance Velikost Počet vCPU Očekávaná šířka pásma sítě (Mb/s) Požadavky GET za sekundu bez SSL (velikost hodnoty 1 kB) Požadavky GET za sekundu s protokolem SSL (velikost hodnoty 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

Zásady clusteru operačního systému

Instance Velikost Počet vCPU Očekávaná šířka pásma sítě (Mb/s) Požadavky GET za sekundu bez SSL (velikost hodnoty 1 kB) Požadavky GET za sekundu s protokolem SSL (velikost hodnoty 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

Podnikové a podnikové úrovně Flash – horizontální navýšení kapacity

Kromě vertikálního navýšení kapacity přesunutím na větší velikost mezipaměti můžete zvýšit výkon horizontálním navýšením kapacity. Ve vrstvách Enterprise se horizontální navýšení kapacity označuje jako zvýšení kapacity instance mezipaměti. Instance mezipaměti má ve výchozím nastavení kapacitu dvousouznamového primárního uzlu a uzlu repliky. Instance podnikové mezipaměti s kapacitou 4 označuje, že instance byla škálována faktorem dvou. Horizontální navýšení kapacity poskytuje přístup k více paměti a virtuálním procesorům. Podrobnosti o tom, kolik virtuálních procesorů používá základní proces Redis při každé velikosti mezipaměti a kapacitě, najdete na stránce osvědčených postupů pro podnikové úrovně. Horizontální navýšení kapacity je nejúčinnější při použití zásad clusteru operačního systému.

Následující tabulky ukazují požadavky GET za sekundu v různých kapacitách pomocí SSL a velikosti hodnoty 1 kB.

Horizontální navýšení kapacity – Zásady podnikového clusteru

Instance Kapacita 2 Kapacita 4 Kapacita 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
Instance Kapacita 3 Kapacita 9
F300 390,000 640,000
F700 370,000 610,000
F1500 390,000 670,000

Horizontální navýšení kapacity – Zásady clusteru operačního systému

Instance Kapacita 2 Kapacita 4 Kapacita 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
Instance Kapacita 3 Kapacita 9
F300 1,200,000 2,600,000
F700 1,200,000 2,600,000
F1500 1,100,000 2,800,000

Další kroky