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 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 Azure Cache for Redis. Jeśli nawiązujesz połączenie 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ń 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 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 sesji dla wersji zapoznawczej usługi Redis .

Aby uzyskać instrukcje dotyczące pobierania narzędzi Usługi 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, aby połączenie ConnectionMultiplexer zostało ponownie nawiązane automatycznie.
  • Użyj pojedynczego, długotrwałego ConnectionMultiplexer wystąpienia, a nie utworzenia nowego połączenia dla każdego żądania. Przykład zarządzania połączeniem można znaleźć w RedisConnection klasie Connect to the cache with Redisconnection (Nawiązywanie połączenia z pamięcią podręczną za pomocą połączenia Redisconnection).
  • 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żanych za duże. Aby uzyskać więcej informacji, zobacz Opracowywanie najlepszych rozwiązań.
  • Skonfiguruj ustawienia puli wątków , aby uniknąć przekroczenia limitu czasu.
  • Użyj co najmniej domyślnego parametru connectTimeout 5 sekund. Ten interwał daje stackExchange.Redis wystarczający czas, aby ponownie ustanowić połączenie, jeśli istnieje blip sieci.
  • Należy pamiętać o kosztach wydajności skojarzonych z różnymi uruchomionymi operacjami. 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 Azure Cache for Redis, aby wiedzieć o scenariuszach, w których może wystąpić utrata danych.
  • Opracuj system tak, aby mógł obsługiwać błędy połączeń spowodowane stosowaniem poprawek i przechodzeniem w tryb failover.

Testowanie wydajności

  • Zacznij od użycia redis-benchmark.exe , aby uzyskać możliwą przepływność przed napisaniem własnych testów wydajności. Ponieważ redis-benchmark protokół TLS nie obsługuje, należy włączyć port bez protokołu TLS za pośrednictwem Azure Portal przed uruchomieniem testu. Aby zapoznać się z przykładami, zobacz Jak mogę przeprowadzić testy porównawcze 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 Azure Cache for Redis.
  • Zalecamy używanie serii maszyn wirtualnych Dv2 dla klienta, ponieważ mają lepszy sprzęt i powinny dać 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 korzystasz z systemu Windows. Zobacz tutaj, aby uzyskać szczegółowe informacje.
  • 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 związane z używaniem typowych poleceń usługi Redis?

  • Unikaj używania niektórych poleceń usługi Redis, które muszą zająć 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 może to potrwać długo. Redis jest serwerem jednowątkowym i przetwarza polecenia pojedynczo. Jeśli masz inne polecenia wydane po klawiszach, 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 klucz/wartości, czy też dużych klucz/wartości? 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 zagadnieniach. 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 innymi zestawami wartości limitu czasu i ponowień, zgodnie z opisem w poprzedniej sekcji Co zrobić z opcjami konfiguracji StackExchange.Redis .

Jak mogę przetestować i przetestować wydajność mojej pamięci podręcznej?

  • Włącz diagnostykę pamięci podręcznej, aby móc monitorować jej kondycję. Metryki można wyświetlić w Azure Portal, a także pobrać i przejrzeć je przy użyciu wybranego narzędzia.
  • Do testowania obciążenia serwera Redis można użyć redis-benchmark.exe.
  • Upewnij się, że klient testowania obciążenia i 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 Usługi 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 wyniki.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 elementu ThreadPool

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 wystąpić w wątku w tle.
  • Wątki IOCP są używane, gdy występuje asynchroniczne operacje we/wy, takie jak podczas odczytywania z sieci.

Pula wątków udostępnia nowe wątki robocze lub wątki uzupełniania we/wy na żądanie (bez 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 wątków (zajętych) osiągnie "minimalną" liczbę wątków, pula wątków ograniczy szybkość, z jaką wprowadza nowe wątki do jednego wątku na 500 milisekund. Zazwyczaj, jeśli system otrzymuje wybuch pracy wymagającej wątku IOCP, będzie on przetwarzał ten proces szybko. Jeśli jednak wzrost jest większy niż skonfigurowane ustawienie "Minimum", istnieje pewne opóźnienie przetwarzania niektórych zadań, ponieważ pula wątków 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 staje się bezpłatny dla 500 ms i tworzony jest nowy wątek.

Zasadniczo, gdy liczba wątków zajęty jest większa niż minimalna, 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 kurczenia 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 PROCESU ROBOCZEgo 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ągnąć 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 dla 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ż wpływać na wydajność innych części skomplikowanych aplikacji, więc każdy klient musi dostosować to ustawienie do swoich konkretnych 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 wpływającym 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 funkcji 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 ramach <processModel> elementu konfiguracji w Machine.configprogramie . 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 elemecie 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 usługi StackExchange.Redis

Włączenie usługi 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 połączeń

Każda warstwa cenowa ma różne limity połączeń klientów, pamięci i przepustowości. Chociaż każdy rozmiar pamięci podręcznej pozwala na maksymalną liczbę połączeń, każde połączenie z usługą Redis wiąże się z nim narzutami. 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 przekroczy 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 Azure Cache for Redis cennik. 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 Azure Cache for Redis często zadawanych pytaniach.