Testowanie wydajności za pomocą usługi Azure Managed Redis

Dotyczy: ✅ Azure Managed Redis

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ć --tls parametry i --tls-skip-verify do polecenia memtier_benchmark.
memtier_benchmark domyś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-mode parametr 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_benchmark z 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 / Notatka

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 / Notatka

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ższej tabeli przedstawiono optymalną przepływność, którą zaobserwowaliśmy podczas testowania różnych rozmiarów wystąpień usługi Azure Managed Redis z obciążeniem składającym się wyłącznie z poleceń odczytu i ładunkiem 1 KB. Obciążenie jest takie samo we wszystkich wariantach SKU, z wyjątkiem liczby połączeń (różne liczby wątków i klientów, zgodnie z wymaganiami narzuconymi przez memtier_benchmark). Liczba połączeń jest dobierana na podstawie jednostki SKU, aby w pełni wykorzystać wystąpienie 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.

Ostrzeżenie

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. Wydajność może się różnić z różnych powodów, takich jak różne liczby połączeń, rozmiar ładunku, wykonywane polecenia itp.

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 określonej generacji w jednym regionie. W praktyce mogą wystąpić różne wyniki, szczególnie 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, szczególnie w przypadku, gdy wymagana jest wysoka wydajność. Aby uzyskać więcej informacji, zobacz Clustering (Klastrowanie).

Rozmiar w GB	Żądania GET na sekundę dla pamięci zoptymalizowanej	Żądania GET na sekundę dla Balanced	Żądania GET na sekundę dla zoptymalizowanych pod kątem obliczeń
0,5	-	120 000	-
1	-	120 000	-
3	-	230,000	480 000
6	-	230,000	480 000
12	230,000	480 000	810,000
24	480 000	810,000	1,600,000
60	810,000	1,500,000	2,000,000
120	1,500,000	2,000,000	2,900,000

W poniższej tabeli wymieniono liczbę połączeń pod względem liczby wątków memtier_benchmark oraz liczby klientów, które zostały użyte do uzyskania wartości przepustowości. Jak wspomniano powyżej, zmiana liczby połączeń może spowodować różną wydajność.

Rozmiar w GB	Liczba klientów/wątków/połączeń zoptymalizowanych pod kątem pamięci	Klienci/wątki/liczba połączeń dla zrównoważonych	Klienty/Wątki/Liczba połączeń dla zoptymalizowanych pod kątem wydajności obliczeń
0,5	-	10/4/40	-
1	-	10/4/40	-
3	-	10/4/40	10/8/80
6	-	10/4/40	10/8/80
12	10/4/40	10/8/80	10/16/160
24	10/8/80	10/16/160	20/16/320
60	10/16/160	20/16/320	20/32/640
120	20/16/320	20/32/640	20/64/1280

Dalsze kroki

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-11-10