Testowanie wydajności za pomocą usługi Azure Managed Redis (wersja zapoznawcza)
Testowanie wydajności wystąpienia usługi Redis może być skomplikowanym zadaniem. Wydajność wystąpienia usługi Redis może się różnić w zależności od parametrów, takich jak liczba klientów, rozmiar wartości danych i to, czy jest używane potokowanie. Może również wystąpić kompromis między optymalizacją przepływności lub opóźnieniami.
Na szczęście istnieje kilka narzędzi ułatwiających porównywanie usługi Redis. Dwa z najpopularniejszych narzędzi to redis-benchmark i memtier-benchmark. Ten artykuł koncentruje się na memtier_benchmark, często nazywanym memtier.
Jak używać narzędzia memtier_benchmark
Zainstaluj rozwiązanie memtier na maszynach wirtualnych klienta, których można użyć do testowania. Postępuj zgodnie z dokumentacją Memtier, aby uzyskać instrukcje dotyczące sposobu instalowania obrazu open source.
Maszyna wirtualna klienta używana do testowania powinna znajdować się w tym samym regionie co wystąpienie usługi Azure Managed Redis (AMR).
Upewnij się, że używana maszyna wirtualna klienta ma co najmniej tyle zasobów obliczeniowych i przepustowości , jak testowane wystąpienie pamięci podręcznej.
Skonfiguruj ustawienia izolacji sieciowej i zapory maszyny wirtualnej, aby upewnić się, że maszyna wirtualna klienta może uzyskać dostęp do wystąpienia usługi Azure Managed Redis.
Jeśli używasz protokołu TLS/SSL w wystąpieniu pamięci podręcznej, musisz dodać
--tlsparametry i--tls-skip-verifydo polecenia memtier_benchmark.memtier_benchmarkdomyślnie używa portu 6379. Użyj parametru-p 10000, aby zastąpić to ustawienie, ponieważ usługa AMR używa portu 10000.W przypadku wszystkich wystąpień usługi Redis zarządzanych przez platformę Azure przy użyciu zasad klastra systemu operacyjnego należy dodać
--cluster-modeparametr do polecenia memtier. Wystąpienia usługi AMR korzystające z zasad klastra przedsiębiorstwa mogą być traktowane jako nieklastrowane pamięci podręczne i nie wymagają tego ustawienia.Uruchom polecenie
memtier_benchmarkz poziomu interfejsu wiersza polecenia lub powłoki maszyny wirtualnej. Aby uzyskać instrukcje dotyczące konfigurowania i uruchamiania narzędzia, zobacz dokumentację Memtier.
Rekomendacje dotyczące testów porównawczych
Jeśli nie uzyskujesz wymaganej wydajności, spróbuj skalować w górę do bardziej zaawansowanej warstwy. Warstwa Zrównoważone zwykle ma dwa razy więcej procesorów wirtualnych jako warstwy Zoptymalizowane pod kątem pamięci, a warstwa Zoptymalizowana pod kątem obliczeń ma zwykle dwa razy więcej procesorów wirtualnych jako warstwy Zrównoważone. Ponieważ usługa Azure Managed Redis jest oparta na usłudze Redis Enterprise, a nie w społeczności redis, podstawowy proces usługi Redis może korzystać z wielu procesorów wirtualnych. W związku z tym wystąpienia z większą liczbie procesorów wirtualnych mają znacznie lepszą wydajność przepływności.
Skalowanie w górę do większych rozmiarów pamięci zwiększa również więcej procesorów wirtualnych, zwiększając wydajność. Jednak skalowanie w górę do większych rozmiarów pamięci jest zwykle mniej skuteczne niż użycie bardziej wydajnej warstwy. Zobacz Warstwy i jednostki SKU w skrócie , aby uzyskać szczegółowy podział procesorów wirtualnych dostępnych dla każdego rozmiaru i warstwy.
Testowanie porównawcze warstwy Zoptymalizowane pod kątem flash może być trudne, ponieważ niektóre klucze są przechowywane na pamięci DRAM, podczas gdy niektóre są przechowywane na dysku flash NVMe. Klucze w teście porównawczym DRAM prawie tak szybko, jak inne wystąpienia usługi Azure Managed Redis, ale klucze na dysku flash NVMe są wolniejsze. Ponieważ warstwa Zoptymalizowana pod kątem flash inteligentnie umieszcza najczęściej używane klucze w pamięci DRAM, upewnij się, że konfiguracja testu porównawczego jest zgodna z rzeczywistym użyciem, którego oczekujesz.
Użycie protokołu TLS/SSL zmniejsza wydajność przepływności, ale jest zdecydowanie zalecane jako najlepsze rozwiązanie produkcyjne.
Przed rozpoczęciem testów porównawczych należy najpierw wypełnić wystąpienie usługi Redis danymi. Testowanie porównawcze pustej pamięci podręcznej daje znacznie lepsze wyniki niż w praktyce.
Liczba używanych połączeń ma znaczący wpływ na test porównawczy. Użycie zbyt wielu połączeń zaczyna obniżać wydajność pamięci podręcznej. Użycie zbyt kilku połączeń nie pokazuje pełnej wydajności pamięci podręcznej. Zalecamy skonfigurowanie liczby połączeń na podstawie rzeczywistych potrzeb aplikacji. Łączna liczba połączeń jest określana przez pomnożenie liczby klientów przez liczbę wątków.
Konfiguracja potoku ma znaczący wpływ na testowanie wydajnościowe. Jeśli ustawisz ustawienie potoku na większe, zobaczysz większą przepływność, ale gorsze opóźnienie. Aby uzyskać więcej informacji, zobacz potokowanie.
przykłady memtier_benchmark
Uwaga
W tym przykładzie pokazano testy porównawcze dla wystąpienia zoptymalizowanego pod kątem obliczeń X3 przy użyciu zasad klastra systemu operacyjnego i protokołu TLS.
Konfiguracja przed testem: przygotuj wystąpienie pamięci podręcznej z danymi wymaganymi do testowania. Załadowanie wystąpienia przy użyciu danych gwarantuje, że wyniki będą dokładniej odzwierciedlać rzeczywiste warunki. Parametr {number-of-keys} powinien być określany przez rozmiar wystąpienia usługi AMR i rozmiar każdego klucza. Dobrą regułą jest wypełnienie wystąpienia w przybliżeniu 75% pełne, co stanowi. Możesz użyć tej formuły: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Jeśli na przykład wykonujesz testy porównawcze w wystąpieniu X3 zoptymalizowanym pod kątem obliczeń, używając 1024-bajtowych rozmiarów kluczy, jak pokazano wcześniej, oznacza {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)to . Wynik jest równy około 1699 396 kluczy.
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
Uwaga
W tym przykładzie użyto --tlsflag , --tls-skip-verifyi --cluster-mode . Nie są one potrzebne, jeśli używasz usługi Azure Managed Redis w trybie innym niż TLS lub jeśli używasz odpowiednio zasad klastra przedsiębiorstwa.
Aby przetestować przepływność: to polecenie testuje potokowe żądania GET z ładunkiem 1k. Użyj tego polecenia, aby przetestować oczekiwaną przepływność odczytu z wystąpienia pamięci podręcznej. W tym przykładzie założono, że używasz protokołu TLS i zasad klastra systemu operacyjnego. Parametr --key-pattern=R:R zapewnia dostęp do kluczy losowo, zwiększając realizm testu porównawczego. Ten test jest uruchamiany przez pięć 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
Przykładowe dane testu porównawczego wydajności
W poniższych tabelach przedstawiono maksymalne wartości przepływności zaobserwowane podczas testowania różnych rozmiarów wystąpień usługi Azure Managed Redis. Użyliśmy z memtier_benchmark maszyny wirtualnej platformy Azure IaaS względem punktu końcowego usługi Azure Managed Redis, korzystając z poleceń memtier przedstawionych w sekcji memtier_benchmark przykłady . Liczby przepływności dotyczą tylko poleceń GET. Zazwyczaj polecenia SET mają niższą przepływność. Wydajność w świecie rzeczywistym różni się w zależności od konfiguracji i poleceń usługi Redis. Liczby te są podawane jako punkt odniesienia, a nie gwarancja.
Uwaga
Te wartości nie są gwarantowane i nie ma umowy SLA dla tych liczb. Zdecydowanie zalecamy przeprowadzenie własnych testów wydajnościowych w celu określenia odpowiedniego rozmiaru pamięci podręcznej dla aplikacji. Te liczby mogą się zmieniać, gdy okresowo publikujemy nowsze wyniki.
Ważne
Firma Microsoft okresowo aktualizuje podstawową maszynę wirtualną używaną w wystąpieniach pamięci podręcznej. Może to zmienić charakterystykę wydajności z pamięci podręcznej na pamięć podręczną i z regionu na region. Przykładowe wartości testów porównawczych na tej stronie odzwierciedlają sprzęt pamięci podręcznej starszej generacji w jednym regionie. Możesz zobaczyć lepsze lub inne wyniki w praktyce, zwłaszcza w przypadku przepustowości sieci.
Usługa Azure Managed Redis oferuje wybór zasad klastra: Enterprise i OSS. Zasady klastra przedsiębiorstwa to prostsza konfiguracja, która nie wymaga od klienta obsługi klastrowania. Z drugiej strony zasady klastra systemu operacyjnego używają protokołu klastra Redis do obsługi wyższej przepływności. W większości przypadków zalecamy używanie zasad klastra systemu operacyjnego. Aby uzyskać więcej informacji, zobacz Clustering (Klastrowanie).
Testy porównawcze dla obu zasad klastra są wyświetlane w poniższych tabelach. W tabeli zasad klastra systemu operacyjnego dostępne są dwie konfiguracje testów porównawczych:
- 300 połączeń (50 klientów i 6 wątków)
- 2500 połączeń (50 klientów i 50 wątków)
Drugie testy porównawcze są udostępniane, ponieważ 300 połączeń nie wystarczy, aby w pełni zademonstrować wydajność większych wystąpień pamięci podręcznej.
Poniżej przedstawiono przepływność operacji GET na sekundę w ładunku 1 kB dla wystąpień usługi AMR wraz z liczbą połączeń klienckich używanych do testów porównawczych. Wszystkie liczby zostały obliczone dla wystąpień usługi AMR z połączeniami SSL, a przepustowość sieci jest rejestrowana w Mb/s.
Zasady klastra systemu operacyjnego
| Rozmiar w 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 |
Zasady klastra przedsiębiorstwa
| Rozmiar w 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 |