Zarządzanie ładowaniem serwera dla usługi Azure Managed Redis (wersja zapoznawcza)
Rozmiary wartości
Projekt aplikacji klienckiej określa, czy należy przechowywać wiele małych wartości, czy mniejszą liczbę większych wartości. Z perspektywy serwera Redis mniejsze wartości zapewniają lepszą wydajność. Zalecamy utrzymanie rozmiaru wartości mniejszego niż 100 kB.
Jeśli projekt wymaga przechowywania większych wartości w usłudze Azure Managed Redis (wersja zapoznawcza), obciążenie serwera będzie wyższe. W takim przypadku może być konieczne użycie wyższej warstwy pamięci podręcznej w celu zapewnienia, że użycie procesora CPU nie będzie ograniczać przepływności.
Nawet jeśli pamięć podręczna ma wystarczającą pojemność procesora CPU, większe wartości zwiększają opóźnienia, dlatego postępuj zgodnie ze wskazówkami podanymi w temacie Konfigurowanie odpowiednich limitów czasu.
Unikanie skokowych wzrostów liczby połączeń klientów
Tworzenie i zamykanie połączeń jest kosztowną operacją dla serwera Redis. Jeśli aplikacja kliencka tworzy lub zamyka zbyt wiele połączeń w krótkim czasie, może to spowodować obciążenie serwera Redis.
Jeśli tworzysz wystąpienie wielu wystąpień klienta w celu nawiązania połączenia z usługą Redis jednocześnie, rozważ rozciągnięcie tworzenia nowych połączeń, aby uniknąć gwałtownego wzrostu liczby połączonych klientów.
Wykorzystanie pamięci
Wysokie użycie pamięci na serwerze zwiększa prawdopodobieństwo, że system musi stronicować dane na dysku, co powoduje błędy stron, które mogą znacznie spowolnić system.
Unikanie długotrwałych poleceń
Serwer Redis to system jednowątkowy. Długotrwałe polecenia mogą powodować opóźnienia lub przekroczenia limitu czasu po stronie klienta, ponieważ serwer nie może odpowiadać na żadne inne żądania, gdy jest zajęty pracą nad długotrwałym poleceniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z usługą Azure Cache for Redis po stronie serwera.
Monitorowanie obciążenia serwera
Dodaj monitorowanie obciążenia serwera, aby mieć pewność, że otrzymasz powiadomienia, gdy wystąpi duże obciążenie serwera. Monitorowanie może ułatwić zrozumienie ograniczeń aplikacji. Następnie możesz aktywnie pracować, aby rozwiązać problemy. Zalecamy próbę utrzymania obciążenia serwera poniżej 80%, aby uniknąć negatywnych efektów wydajności. Trwałe obciążenie serwera ponad 80% może prowadzić do nieplanowanych trybów failover. Obecnie usługa Azure Managed Redis uwidacznia dwie metryki w obszarze Monitorowanie w menu Zasób po lewej stronie portalu: procesor CPU i obciążenie serwera. Zrozumienie, co jest mierzone przez każdą metrykę, jest ważne podczas monitorowania obciążenia serwera.
Metryka procesora CPU wskazuje użycie procesora CPU dla węzła, który hostuje pamięć podręczną. Metryka procesora CPU obejmuje również procesy, które nie są ściśle procesami serwera Redis. Procesor CPU obejmuje procesy w tle dla ochrony przed złośliwym oprogramowaniem i inne. W związku z tym metryka procesora CPU może czasami gwałtownie zwiększać się i może nie być doskonałym wskaźnikiem użycia procesora CPU dla serwera Redis.
Metryka Obciążenie serwera reprezentuje obciążenie samego serwera Redis. Zalecamy monitorowanie metryki Obciążenie serwera zamiast procesora CPU.
Podczas monitorowania obciążenia serwera zalecamy również sprawdzenie maksymalnych skoków obciążenia serwera, a nie średnich, ponieważ nawet krótkie skoki mogą wyzwalać przejścia w tryb failover i limity czasu poleceń.
Planowanie konserwacji serwera
Upewnij się, że masz wystarczającą wydajność serwera do obsługi szczytowego obciążenia podczas konserwacji serwerów pamięci podręcznej. Przetestuj system, uruchamiając ponownie węzły podczas szczytowego obciążenia. Aby uzyskać więcej informacji na temat symulowania wdrażania poprawki, zobacz ponowne uruchamianie.
Testowanie zwiększonego obciążenia serwera po przejściu w tryb failover
W przypadku jednostek SKU w warstwie Standardowa i Premium każda pamięć podręczna jest hostowana w dwóch węzłach. Moduł równoważenia obciążenia dystrybuuje połączenia klienta między dwa węzły. Gdy planowana lub nieplanowana konserwacja odbywa się w węźle podstawowym, węzeł zamyka wszystkie połączenia klienta. W takich sytuacjach wszystkie połączenia klienta mogą trafić do jednego węzła, co powoduje zwiększenie obciążenia serwera w jednym pozostałym węźle. Zalecamy przetestowanie tego scenariusza przez ponowne uruchomienie węzła podstawowego i upewnienie się, że jeden węzeł może obsłużyć wszystkie połączenia klienckie bez zbyt dużego obciążenia serwera.