Zarządzanie usługą Azure Managed Redis (wersja zapoznawcza) — często zadawane pytania

Używanie protokołu TLS jest zalecane jako najlepsze rozwiązanie dla praktycznie wszystkich przypadków użycia usługi Redis. Opcja nawiązywania połączenia bez protokołu TLS jest uwzględniana w celach zgodności z poprzednimi wersjami.

• StackExchange.Redis — najlepsze rozwiązania
• Konfiguracja i pojęcia
• Testowanie wydajności

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

• 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 Managed 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

• Zobacz Testowanie wydajności za pomocą usługi Azure Managed Redis , na przykład testy porównawcze i instrukcje dotyczące uruchamiania własnych testów wydajnościowych w usłudze Azure Managed 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. Każdy fragment usługi Redis jest jednym wątkiem i przetwarza polecenia pojedynczo naraz. 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 są 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.

• 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.
• Zobacz Testowanie wydajności za pomocą usługi Azure Managed Redis , na przykład testy porównawcze i instrukcje dotyczące uruchamiania własnych testów wydajnościowych w usłudze Azure Managed Redis.

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 wątków (zajętych) osiągnie "minimalną" liczbę wątków, pula ThreadPool ogranicza 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, przetwarza te procesy 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 zobaczy dwa opóźnienia 500 ms, ponieważ 6 > 4.

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 udzielić jednowymiarowych wskazówek dotyczących tego, jaka powinna być ta wartość, ponieważ właściwa wartość dla jednej aplikacji może być 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 maszynę z czterema rdzeniami 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 obszarze <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 elemedycie konfiguracji jest ustawieniem na rdzeń . Jeśli na przykład masz maszynę z czterema rdzeniami i chcesz, aby ustawienie minIoThreads miało wartość 200 w czasie wykonywania, użyj polecenia <processModel minIoThreads="50"/>.

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:

• Aby włączyć GC serwera
• Podstawy dotyczące odzyskiwania pamięci
• Odzyskiwanie pamięci i wydajność

Różne jednostki SKU mogą mieć różne limity dla połączeń klienta, 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 z operacji klienta przekracza pojemność systemu, pamięć podręczna może wystąpić problemy z pojemnością, nawet jeśli nie przekroczysz 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 Managed 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 Managed Redis.