Sdílet prostřednictvím

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če, 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é vrstvy využívající clustering enterprise se dají považovat za neclusterované mezipaměti a toto nastavení nepotřebují.

  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.

  • 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ě.

  • U mezipamětí C0 a C1 Úrovně Standard se v době, kdy na virtuálních počítačích běží interní kontrola Defenderu, můžou nacházet krátké špičky v zatížení serveru, které nejsou způsobené nárůstem požadavků na mezipaměť. Při interních kontrolách Defenderu se na těchto úrovních několikrát denně zobrazuje vyšší latence požadavků. Mezipaměti na úrovních C0 a C1 mají pouze jedno jádro pro vícetask a rozdělují práci obsluhy interní kontroly Defenderu a požadavků Redis. Účinek můžete snížit škálováním na vyšší úroveň nabídky s více jádry procesoru, například C2.

    Zvýšená velikost mezipaměti na vyšších úrovních pomáhá řešit případné problémy s latencí. Na úrovni C2 máte také podporu až pro 2 000 klientských připojení.

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 jsme a memtier-benchmark z virtuálního počítače Azure IaaS jsme použili redis-benchmark 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 z reálného světa za přijatelných podmínek latence může být nižší.

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.

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

Srovnávací testy Redis úrovně 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

Srovnávací testy Redis úrovně 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 naleznete v tématu Clustering . 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) GET požadavky za sekundu bez SSL (velikost hodnoty 1 kB) GET požadavky 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) GET požadavky za sekundu bez SSL (velikost hodnoty 1 kB) GET požadavky 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á proces Core Redis při každé velikosti mezipaměti a kapacitě, najdete v konfiguraci horizontálního dělení. 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 za sekundu GET 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