Zarządzanie usługą Azure Cache for Redis — często zadawane pytania

Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące zarządzania usługą Azure Cache for Redis.

Kiedy należy włączyć port inny niż TLS/SSL na potrzeby nawiązywania połączenia z usługą Redis?

Serwer Redis nie obsługuje natywnie protokołu TLS, ale usługa Azure Cache for Redis działa. Jeśli łączysz się z usługą Azure Cache for Redis, a klient obsługuje protokół TLS, taki jak StackExchange.Redis, użyj protokołu TLS.

Uwaga

Port inny niż TLS jest domyślnie wyłączony dla nowych wystąpień usługi Azure Cache for Redis. Jeśli klient nie obsługuje protokołu TLS, musisz włączyć port inny niż TLS, postępując zgodnie z instrukcjami w sekcji Porty dostępu w artykule Konfigurowanie pamięci podręcznej w usłudze Azure Cache for Redis.

Narzędzia usługi Redis, takie jak redis-cli nie działają z portem TLS, ale możesz użyć narzędzia, takiego jak stunnel bezpieczne łączenie narzędzi z portem TLS, postępując zgodnie z instrukcjami w wpisie w blogu Ogłaszanie dostawcy stanu sesji ASP.NET dla usługi Redis w wersji zapoznawczej .

Aby uzyskać instrukcje dotyczące pobierania narzędzi Redis, zobacz sekcję Jak mogę uruchomić polecenia usługi Redis?

Jakie są najlepsze rozwiązania dotyczące produkcji?

StackExchange.Redis — najlepsze rozwiązania

  • Ustaw AbortConnect wartość false, a następnie pozwól na automatyczne ponowne nawiązanie połączenia z elementem ConnectionMultiplexer.
  • Użyj pojedynczego, długotrwałego ConnectionMultiplexer wystąpienia zamiast tworzenia nowego połączenia dla każdego żądania.
  • Usługa Redis działa najlepiej z mniejszymi wartościami, dlatego rozważ posiekanie większych danych do wielu kluczy. W tej dyskusji redis 100 kb jest uważany za duży. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania programistyczne.
  • Skonfiguruj ustawienia puli wątków, aby uniknąć przekroczenia limitu czasu.
  • Użyj co najmniej domyślnego parametru connectTimeout 5 sekund. Ten interwał zapewnia usłudze StackExchange.Redis wystarczający czas na ponowne nawiązanie połączenia, jeśli istnieje blip sieci.
  • Należy pamiętać o kosztach wydajności związanych z różnymi operacjami, które są uruchomione. Na przykład KEYS polecenie jest operacją O(n) i należy unikać. Witryna redis.io zawiera szczegółowe informacje dotyczące złożoności czasu dla każdej obsługiwanej operacji. Wybierz każde polecenie, aby zobaczyć złożoność każdej operacji.

Konfiguracja i pojęcia

  • Użyj warstwy Standardowa lub Premium dla systemów produkcyjnych. Warstwa Podstawowa to system z jednym węzłem bez replikacji danych i bez umowy SLA. Ponadto można użyć przynajmniej pamięci podręcznej C1. Pamięci podręczne C0 są zwykle używane w prostych scenariuszach tworzenia i testowania.
  • Pamiętaj, że usługa Redis jest magazynem danych w pamięci . Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z utratą danych w usłudze Azure Cache for Redis , aby znać scenariusze, w których może wystąpić utrata danych.
  • Opracuj system, tak aby mógł obsługiwać blipy połączeń spowodowane stosowaniem poprawek i trybem failover.

Testowanie wydajności

  • Zacznij od użycia, redis-benchmark.exe aby uzyskać dostęp do możliwej przepływności przed napisaniem własnych testów wydajności. Ponieważ redis-benchmark nie obsługuje protokołu TLS, przed uruchomieniem testu musisz włączyć port bez protokołu TLS za pośrednictwem witryny Azure Portal . Aby zapoznać się z przykładami, zobacz Jak mogę przeprowadzić test porównawczy i przetestować wydajność mojej pamięci podręcznej?
  • Maszyna wirtualna klienta używana do testowania powinna znajdować się w tym samym regionie co wystąpienie usługi Azure Cache for Redis.
  • Zalecamy używanie serii maszyn wirtualnych Dv2 dla klienta, ponieważ mają lepszy sprzęt i powinny zapewnić najlepsze wyniki.
  • Upewnij się, że wybrana maszyna wirtualna klienta ma co najmniej tyle możliwości przetwarzania i przepustowości, jak pamięć podręczna, którą testujesz.
  • Włącz usługę VRSS na komputerze klienckim, jeśli jesteś w systemie Windows. Aby uzyskać szczegółowe informacje, zobacz tutaj.
  • Wystąpienia usługi Redis w warstwie Premium mają lepsze opóźnienie sieci i przepływność, ponieważ działają na lepszym sprzęcie zarówno dla procesora CPU, jak i sieci.

Jakie są niektóre zagadnienia dotyczące używania typowych poleceń usługi Redis?

  • Unikaj używania niektórych poleceń usługi Redis, które zajmują dużo czasu, chyba że w pełni zrozumiesz wynik tych poleceń. Na przykład nie uruchamiaj polecenia KEYS w środowisku produkcyjnym. W zależności od liczby kluczy powrót może zająć dużo czasu. Redis to serwer jednowątkowy, który jednocześnie przetwarza polecenia. Jeśli masz inne polecenia wydane po kluczu, nie są przetwarzane, dopóki usługa Redis nie przetworzy polecenia KEYS. Witryna redis.io zawiera szczegółowe informacje dotyczące złożoności czasu dla każdej obsługiwanej operacji. Wybierz każde polecenie, aby zobaczyć złożoność każdej operacji.
  • Rozmiary kluczy — czy należy używać małych kluczy/wartości, czy dużych wartości/kluczy? Zależy to od scenariusza. Jeśli scenariusz wymaga większych kluczy, możesz dostosować wartość ConnectionTimeout, a następnie ponowić próbę i dostosować logikę ponawiania prób. Z perspektywy serwera Redis mniejsze wartości zapewniają lepszą wydajność.
  • Te zagadnienia nie oznaczają, że nie można przechowywać większych wartości w usłudze Redis; Należy pamiętać o następujących kwestiach. Opóźnienia będą wyższe. Jeśli masz jeden zestaw danych, który jest większy i mniejszy, możesz użyć wielu wystąpień ConnectionMultiplexer. Skonfiguruj każdy z nich przy użyciu innego zestawu wartości limitu czasu i ponawiania prób, zgodnie z opisem w poprzedniej sekcji Co zrobić opcje konfiguracji StackExchange.Redis.

Jak przeprowadzić test porównawczy i przetestować wydajność mojej pamięci podręcznej?

  • Włącz diagnostykę pamięci podręcznej, aby móc monitorować jej kondycję. Możesz wyświetlać metryki w witrynie Azure Portal oraz pobierać i przeglądać je przy użyciu wybranych przez siebie narzędzi.
  • Do testowania obciążenia serwera Redis można użyć redis-benchmark.exe.
  • Upewnij się, że klient testowania obciążenia i usługa Azure Cache for Redis znajdują się w tym samym regionie.
  • Użyj redis-cli.exe i monitoruj pamięć podręczną przy użyciu polecenia INFO.
  • Jeśli obciążenie powoduje fragmentację pamięci, należy skalować w górę do większego rozmiaru pamięci podręcznej.
  • Aby uzyskać instrukcje dotyczące pobierania narzędzi Redis, zobacz sekcję Jak mogę uruchomić polecenia usługi Redis?

Oto kilka przykładów użycia redis-benchmark.exe. Uruchom te polecenia z maszyny wirtualnej w tym samym regionie co pamięć podręczna, aby uzyskać dokładne results.cache-development-faq.yml

  • Testowanie żądań SET potokowych przy użyciu ładunku 1k

    redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

  • Przetestuj żądania GET potoku przy użyciu ładunku 1k.

Uwaga

Uruchom powyższy test SET, aby wypełnić pamięć podręczną

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

Ważne szczegóły dotyczące wzrostu puli wątków

Pula wątków CLR ma dwa typy wątków — "Proces roboczy" i "Port uzupełniania we/wy" (IOCP).

  • Wątki procesów roboczych są używane do przetwarzania Task.Run(…)metod lub ThreadPool.QueueUserWorkItem(…) . Te wątki są również używane przez różne składniki środowiska CLR, gdy praca musi odbywać się w wątku w tle.
  • Wątki IOCP są używane w przypadku asynchronicznego we/wy, na przykład podczas odczytywania z sieci.

Pula wątków udostępnia nowe wątki robocze lub wątki uzupełniania we/wy na żądanie (bez żadnego ograniczania), dopóki nie osiągnie ustawienia "Minimum" dla każdego typu wątku. Domyślnie minimalna liczba wątków jest ustawiana na liczbę procesorów w systemie.

Gdy liczba istniejących (zajętych) wątków osiągnie "minimalną" liczbę wątków, pula ThreadPool ograniczy szybkość, z jaką wprowadza nowe wątki do jednego wątku na 500 milisekund. Zazwyczaj, jeśli system dostaje serię pracy wymagającej wątku IOCP, proces ten będzie przebiegał szybko. Jeśli jednak wzrost jest większy niż skonfigurowane ustawienie "Minimum", istnieje pewne opóźnienie przetwarzania niektórych zadań, ponieważ funkcja ThreadPool czeka na jedną z dwóch możliwości:

  • Istniejący wątek staje się wolny do przetwarzania pracy.
  • Żaden istniejący wątek nie zostanie bezpłatny dla 500 ms i zostanie utworzony nowy wątek.

Zasadniczo, gdy liczba wątków zajętych jest większa niż Minimalna liczba wątków, prawdopodobnie płacisz opóźnienie 500 ms przed przetworzeniem ruchu sieciowego przez aplikację. Ponadto, gdy istniejący wątek pozostaje bezczynny przez dłużej niż 15 sekund, jest czyszczony, a ten cykl wzrostu i zmniejszania może się powtarzać.

Jeśli spojrzymy na przykładowy komunikat o błędzie z witryny StackExchange.Redis (kompilacja 1.0.450 lub nowsza), zobaczymy, że teraz wyświetla statystyki threadpool. Zobacz szczegóły IOCP i WORKER poniżej.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Jak pokazano w przykładzie, widać, że w wątku IOCP istnieją sześć zajętych wątków, a system jest skonfigurowany tak, aby zezwalał na cztery minimalne wątki. W takim przypadku klient prawdopodobnie widziałby dwa opóźnienia 500 ms, ponieważ 6 > 4.

Uwaga

StackExchange.Redis może osiągać limity czasu, jeśli wzrost wątków IOCP lub WORKER zostanie ograniczony.

Zalecenie

Biorąc pod uwagę te informacje, zdecydowanie zalecamy, aby klienci ustawili minimalną wartość konfiguracji wątków IOCP i WORKER na wartość większą niż wartość domyślna. Nie możemy podać wskazówek dotyczących tego, jaka powinna być ta wartość, ponieważ właściwa wartość dla jednej aplikacji prawdopodobnie będzie zbyt wysoka lub niska dla innej aplikacji. To ustawienie może również mieć wpływ na wydajność innych części skomplikowanych aplikacji, więc każdy klient musi dostosować to ustawienie do określonych potrzeb. Dobrym miejscem wyjścia jest 200 lub 300, a następnie przetestuj i dostosuj zgodnie z potrzebami.

Jak skonfigurować to ustawienie:

  • Zalecamy programowe zmianę tego ustawienia przy użyciu metody ThreadPool.SetMinThreads (...) w pliku global.asax.cs. Na przykład:

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }
    

    Uwaga

    Wartość określona przez tę metodę jest ustawieniem globalnym, które wpływa na całą domenę aplikacji. Jeśli na przykład masz 4-rdzeniową maszynę i chcesz ustawić wartości minWorkerThreads i minIoThreads na 50 na procesor w czasie wykonywania, użyj elementu ThreadPool.SetMinThreads(200, 200).

  • Istnieje również możliwość określenia ustawienia minimalnych wątków przy użyciu ustawienia konfiguracji minIoThreads lub minWorkerThreads w elemenie <processModel> konfiguracji w Machine.configelemecie . Machine.config zazwyczaj znajduje się w lokalizacji %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Ustawienie liczby minimalnych wątków w ten sposób nie jest zalecane, ponieważ jest to ustawienie dla całego systemu.

    Uwaga

    Wartość określona w tym elemedycie konfiguracji jest ustawieniem na rdzeń . Jeśli na przykład masz 4-rdzeniową maszynę i chcesz, aby ustawienie minIoThreads miało wartość 200 w czasie wykonywania, użyj polecenia <processModel minIoThreads="50"/>.

Włącz GC serwera, aby uzyskać większą przepływność na kliencie podczas korzystania z stackExchange.Redis

Włączenie kontrolera GC serwera może zoptymalizować klienta i zapewnić lepszą wydajność i przepływność podczas korzystania z usługi StackExchange.Redis. Aby uzyskać więcej informacji na temat GC serwera i sposobu jej włączania, zobacz następujące artykuły:

Zagadnienia dotyczące wydajności dotyczące połączeń

Każda warstwa cenowa ma różne limity dla połączeń klientów, pamięci i przepustowości. Chociaż każdy rozmiar pamięci podręcznej umożliwia maksymalną liczbę połączeń, każde połączenie z usługą Redis ma związane z nim obciążenie. Przykładem takiego obciążenia jest użycie procesora CPU i pamięci z powodu szyfrowania TLS/SSL. Maksymalny limit połączeń dla danego rozmiaru pamięci podręcznej zakłada lekko załadowaną pamięć podręczną. Jeśli obciążenie związane z obciążeniem połączenia i obciążeniem operacji klienta przekracza pojemność systemu, pamięć podręczna może wystąpić problemy z pojemnością, nawet jeśli nie przekroczono limitu połączenia dla bieżącego rozmiaru pamięci podręcznej.

Aby uzyskać więcej informacji na temat różnych limitów połączeń dla każdej warstwy, zobacz Cennik usługi Azure Cache for Redis. Aby uzyskać więcej informacji na temat połączeń i innych konfiguracji domyślnych, zobacz Domyślna konfiguracja serwera Redis.

Następne kroki

Dowiedz się więcej o innych często zadawanych pytaniach dotyczących usługi Azure Cache for Redis.