Zarządzanie pamięcią podręczną — często zadawane pytania

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

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

• Służy redis-benchmark.exe do testowania obciążenia serwera Redis. Użyj redis-benchmark.exe , aby zapoznać się z możliwą przepływnością przed napisaniem własnych testów wydajności.
• Służy redis-cli do monitorowania pamięci podręcznej za pomocą INFO polecenia. Aby uzyskać instrukcje dotyczące pobierania narzędzi Redis, zobacz Jak mogę uruchamiać polecenia Redis?
• Jeśli używasz protokołu Transport Layer Security/Secure Socket Layer (TLS/SSL) w wystąpieniu pamięci podręcznej, dodaj --tls parametr do poleceń narzędzi Redis Tools lub użyj serwera proxy, takiego jak stunnel włączenie protokołu TLS/SSL.
• Redis-benchmark Domyślnie używa portu 6379 . Użyj parametru, -p aby zastąpić to ustawienie, jeśli pamięć podręczna korzysta z portu 6380 SSL/TLS lub portu 10000warstwy Enterprise.
• W razie potrzeby możesz włączyć port inny niż TLS za pośrednictwem Azure Portal przed uruchomieniem testu obciążeniowego.
• Upewnij się, że kliencka maszyna wirtualna używana do testowania znajduje się w tym samym regionie co wystąpienie Azure Cache for Redis.
• Upewnij się, że maszyna wirtualna klienta ma co najmniej taką samą moc obliczeniową i przepustowość jak testowana pamięć podręczna. Aby uzyskać najlepsze wyniki, użyj maszyn wirtualnych z serii D i E dla klientów.
• Jeśli korzystasz z systemu Windows, włącz wirtualne skalowanie po stronie odbierającej (VRSS) na komputerze klienckim. Aby uzyskać więcej informacji, zobacz Wirtualne skalowanie po stronie odbierającej w systemie Windows Server 2012 R2.
• Włącz diagnostykę pamięci podręcznej, aby móc monitorować kondycję pamięci podręcznej. Metryki można wyświetlić w Azure Portal, a także pobrać i przejrzeć metryki przy użyciu wybranych narzędzi.
• Jeśli obciążenie powoduje dużą fragmentację pamięci, przeskaluj w górę do większego rozmiaru pamięci podręcznej.

W poniższych przykładach pokazano, jak używać redis-benchmark.exeprogramu . Uruchom te polecenia z maszyny wirtualnej w tym samym regionie co pamięć podręczna, aby uzyskać dokładne wyniki.

Najpierw przetestuj żądania potokowe SET przy użyciu ładunku 1k:

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

Po uruchomieniu SET testu uruchom potokowe GET żądania przy użyciu ładunku 1k:

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

Jak mogę włączyć GC serwera, aby uzyskać większą przepływność na kliencie podczas korzystania z StackExchange.Redis?

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

• Element <gcServer>
• Podstawy wyrzucania elementów bezużytecznych
• Odzyskiwanie pamięci i wydajność

Czy powinienem włączyć port inny niż TLS/SSL do nawiązywania połączenia z Redis?

Serwer Redis nie obsługuje natywnie protokołu Transport Layer Security (TLS), ale Azure Cache for Redis obsługuje protokół TLS. Jeśli łączysz się z Azure Cache for Redis za pomocą klienta, takiego jak StackExchange.Redis, który obsługuje protokół TLS, użyj protokołu TLS.

Uwaga

Port inny niż TLS jest domyślnie wyłączony dla nowych wystąpień usługi Azure Redis. Jeśli klient nie obsługuje protokołu TLS, włącz port inny niż TLS, postępując zgodnie z instrukcjami w temacie Porty dostępu.

Jeśli pamięć podręczna używa protokołu TLS, należy włączyć protokół TLS, korzystając z --tls opcji narzędzi Redis, takich jak redis-cli. Możesz również użyć narzędzia, takiego jak stunnel bezpieczne połączenie narzędzi z portem TLS, postępując zgodnie ze wskazówkami we wpisie w blogu Ogłasza ASP.NET nie dostawcy stanu sesji dla wersji zapoznawczej usługi Redis .

Aby uzyskać instrukcje dotyczące pobierania narzędzi Redis, zobacz Jak mogę uruchamiać polecenia Redis?

Jakie zagadnienia należy wziąć pod uwagę przy korzystaniu z 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 przetwarza polecenia pojedynczo. Jeśli wydasz KEYS polecenie, usługa Redis nie przetworzy kolejnych poleceń, dopóki nie zakończy przetwarzania KEYS polecenia.

  Witryna redis.io zawiera szczegółowe informacje o złożoności czasowej dla każdej obsługiwanej operacji. Wybierz każde polecenie, aby zobaczyć złożoność każdej operacji.

• Rozmiar kluczy do użycia zależy od scenariusza. Jeśli scenariusz wymaga większych kluczy, możesz dostosować ConnectionTimeoutwartości , a następnie ponowić próbę i dostosować logikę ponawiania prób. Z perspektywy serwera Redis mniejsze wartości kluczy zapewniają lepszą wydajność.

• Te zagadnienia nie oznaczają, że nie można przechowywać większych wartości w usłudze Redis, ale opóźnienia są większe. Jeśli masz jeden zestaw danych, który jest większy niż inny, możesz użyć wielu ConnectionMultiplexer wystąpień, z których każde jest skonfigurowane z innym zestawem wartości limitu czasu i ponawiania prób. Aby uzyskać więcej informacji, zobacz Do czego służą opcje konfiguracji StackExchange.Redis?

Jakie są wymagania dotyczące wydajności połączeń?

Każda warstwa cenowa Azure Cache for Redis ma różne limity połączeń klientów, pamięci i przepustowości. Chociaż każdy rozmiar pamięci podręcznej pozwala na maksymalnie określoną liczbę połączeń, każde połączenie z usługą Redis wiąże się ze skojarzonym obciążeniem. Przykładem takiego obciążenia jest użycie procesora 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 wynikające z obciążenia połączenia oraz obciążenie spowodowane operacjami klienta przekracza pojemność systemu, w pamięci podręcznej mogą wystąpić problemy z pojemnością, nawet jeśli nie zostanie przekroczony limit połączeń dla bieżącego rozmiaru pamięci podręcznej.

Aby uzyskać więcej informacji na temat 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.

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

• 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 dotyczącej poziomu usług (SLA). Ponadto użyj co najmniej pamięci podręcznej C1 dla środowiska produkcyjnego. Pamięci podręczne C0 są zwykle używane w prostych scenariuszach tworzenia i testowania.
• Należy pamiętać, że Redis jest magazynem danych w pamięci , a w niektórych scenariuszach może dojść do utraty danych. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z utratą danych w Azure Cache for Redis.
• Opracuj swój system tak, aby mógł obsługiwać zakłócenia połączeń spowodowane poprawkami i przełączaniem awaryjnym.
• Korzystaj z wystąpień usługi Azure Redis w warstwie Premium, aby uzyskać większe opóźnienia i przepływność sieci, ponieważ mają one lepszy sprzęt zarówno dla procesora CPU, jak i sieci.

StackExchange.Redis — najlepsze rozwiązania

• Ustaw AbortConnect wartość false, a następnie pozwól na automatyczne ponowne połączenie 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. Na przykład w polu Jaki jest idealny zakres rozmiarów wartości dla redis?, 100 kb jest uważane za duże. Aby uzyskać więcej informacji, zobacz Uwzględnianie większej liczby kluczy i mniejszych wartości.
• Skonfiguruj ustawienia puli wątków, aby uniknąć przekroczenia limitu czasu.
• Użyj wartości domyślnej connectTimeout co najmniej 5 sekund. Ten interwał daje usłudze StackExchange.Redis wystarczający czas na ponowne nawiązanie połączenia, jeśli wystąpi blip sieci.
• Należy pamiętać o kosztach wydajności związanych z różnymi uruchamianymi operacjami. Na przykład KEYS polecenie jest operacją O(n) i należy unikać. Witryna redis.io zawiera szczegółowe informacje na temat złożoności czasowej każdej obsługiwanej operacji. Wybierz każde polecenie, aby zobaczyć złożoność każdej operacji.

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

Pula wątków środowiska uruchomieniowego języka wspólnego (CLR) ma dwa typy wątków: proces roboczy i port ukończenia we/wy (IOCP).

• WORKER Wątki są używane do takich rzeczy, jak przetwarzanie Task.Run(…)metod lub ThreadPool.QueueUserWorkItem(…) . Różne składniki w CLR również używają tych wątków, gdy praca musi zostać wykonana w wątku w tle.
• IOCP wątki są używane do asynchronicznych operacji we/wy, na przykład podczas odczytu z sieci.

Pula wątków udostępnia nowe wątki robocze lub wątki ukończenia we/wy na żądanie bez żadnego ograniczania przepustowości, dopóki nie osiągnie minimum ustawienia 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 minimum liczbę wątków, pula wątków ogranicza szybkość, z jaką wstrzykuje nowe wątki do jednego wątku na 500 milisekund.

Zazwyczaj, jeśli system otrzymuje serię pracy, która wymaga IOCP wątku, przetwarza to szybko. Jeśli jednak seria jest większa niż skonfigurowane minimum ustawienie, występuje pewne opóźnienie w przetwarzaniu 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ę wolny przez 500 ms, więc tworzony jest nowy wątek.

Zasadniczo, gdy liczba Busy wątków jest większa niż Min liczba wątków, występuje opóźnienie 500 ms, zanim aplikacja przetworzy ruch sieciowy. Ponadto istniejąca nić, która pozostaje bezczynna przez ponad 15 sekund, jest czyszczona, a ten cykl wzrostu i kurczenia się może się powtórzyć.

Komunikaty o błędach z StackExchange.Redis w wersji 1.0.450 lub nowszej drukują statystyki puli wątków, jak pokazano w poniższym przykładzie.

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)

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

Uwaga

StackExchange.Redis może osiągnąć przekroczenie limitu czasu, jeśli wzrost jednego IOCP z wątków lub WORKER jest ograniczony.

Najlepiej ustawić minimalną wartość konfiguracji dla IOCP i WORKER wątków na wartość większą niż wartość domyślna. Nie ma jednego uniwersalnego przewodnika dotyczącego tej wartości, ponieważ właściwa wartość dla jednej aplikacji jest prawdopodobnie zbyt wysoka lub niska dla innej aplikacji. To ustawienie może również wpływać na wydajność innych części skomplikowanych aplikacji. Musisz dostosować to ustawienie do swoich konkretnych potrzeb. Dobrym punktem wyjścia jest 200 lub 300. Następnie przetestuj i dostosuj w razie potrzeby.

Konfigurowanie ustawienia minimalnej liczby wątków

To ustawienie można zmienić programowo przy użyciu metody ThreadPool.SetMinThreads (...) .

Na przykład w NET Framework należy ustawić tę wartość w Global.asax.cs w metodzie Application_Start :

    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);
    }

Jeśli używasz platformy .NET Core, należy ustawić wartość w Program.cs tuż przed wywołaniem :WebApplication.CreateBuilder()

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Uwaga

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

Możliwe jest również określenie ustawienia minimalnej liczby wątków przy użyciu minIoThreadsminWorkerThreads or w elemencie <processModel> konfiguracji w programieMachine.config. Machine.config zwykle znajduje się pod adresem %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Ustawianie minimalnej liczby wątków w ten sposób nie jest zalecane, ponieważ jest to ustawienie obejmujące cały system. Jeśli w ten sposób ustawisz minimalną liczbę wątków, musisz ponownie uruchomić pulę aplikacji.

Uwaga

Wartość określona przez tę metodę jest ustawieniem na rdzeń . Na przykład, jeśli masz komputer czterordzeniowy i chcesz, aby ustawienie minIoThreads wynosiło 200 w czasie wykonywania, użyj <processModel minIoThreads="50">.

Treści powiązane

• Zobacz inne często zadawane pytania dotyczące usługi Azure Cache for Redis.

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

• Służy redis-benchmark.exe do testowania obciążenia serwera Redis. Użyj redis-benchmark.exe , aby zapoznać się z możliwą przepływnością przed napisaniem własnych testów wydajności.
• Służy redis-cli do monitorowania pamięci podręcznej za pomocą INFO polecenia. Aby uzyskać instrukcje dotyczące pobierania narzędzi Redis, zobacz Jak mogę uruchamiać polecenia Redis?
• Jeśli używasz protokołu Transport Layer Security/Secure Socket Layer (TLS/SSL) w wystąpieniu pamięci podręcznej, dodaj --tls parametr do poleceń narzędzi Redis Tools lub użyj serwera proxy, takiego jak stunnel włączenie protokołu TLS/SSL.
• Redis-benchmark Domyślnie używa portu 6379 . Użyj parametru, -p aby zastąpić to ustawienie, jeśli pamięć podręczna korzysta z portu 6380 SSL/TLS lub portu 10000warstwy Enterprise.
• W razie potrzeby możesz włączyć port inny niż TLS za pośrednictwem Azure Portal przed uruchomieniem testu obciążeniowego.
• Upewnij się, że kliencka maszyna wirtualna używana do testowania znajduje się w tym samym regionie co wystąpienie Azure Cache for Redis.
• Upewnij się, że maszyna wirtualna klienta ma co najmniej taką samą moc obliczeniową i przepustowość jak testowana pamięć podręczna. Aby uzyskać najlepsze wyniki, użyj maszyn wirtualnych z serii D i E dla klientów.
• Jeśli korzystasz z systemu Windows, włącz wirtualne skalowanie po stronie odbierającej (VRSS) na komputerze klienckim. Aby uzyskać więcej informacji, zobacz Wirtualne skalowanie po stronie odbierającej w systemie Windows Server 2012 R2.
• Włącz diagnostykę pamięci podręcznej, aby móc monitorować kondycję pamięci podręcznej. Metryki można wyświetlić w Azure Portal, a także pobrać i przejrzeć metryki przy użyciu wybranych narzędzi.
• Jeśli obciążenie powoduje dużą fragmentację pamięci, przeskaluj w górę do większego rozmiaru pamięci podręcznej.

W poniższych przykładach pokazano, jak używać redis-benchmark.exeprogramu . Uruchom te polecenia z maszyny wirtualnej w tym samym regionie co pamięć podręczna, aby uzyskać dokładne wyniki.

Najpierw przetestuj żądania potokowe SET przy użyciu ładunku 1k:

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

Po uruchomieniu SET testu uruchom potokowe GET żądania przy użyciu ładunku 1k:

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

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

• Element <gcServer>
• Podstawy wyrzucania elementów bezużytecznych
• Odzyskiwanie pamięci i wydajność

Serwer Redis nie obsługuje natywnie protokołu Transport Layer Security (TLS), ale Azure Cache for Redis obsługuje protokół TLS. Jeśli łączysz się z Azure Cache for Redis za pomocą klienta, takiego jak StackExchange.Redis, który obsługuje protokół TLS, użyj protokołu TLS.

Uwaga

Port inny niż TLS jest domyślnie wyłączony dla nowych wystąpień usługi Azure Redis. Jeśli klient nie obsługuje protokołu TLS, włącz port inny niż TLS, postępując zgodnie z instrukcjami w temacie Porty dostępu.

Jeśli pamięć podręczna używa protokołu TLS, należy włączyć protokół TLS, korzystając z --tls opcji narzędzi Redis, takich jak redis-cli. Możesz również użyć narzędzia, takiego jak stunnel bezpieczne połączenie narzędzi z portem TLS, postępując zgodnie ze wskazówkami we wpisie w blogu Ogłasza ASP.NET nie dostawcy stanu sesji dla wersji zapoznawczej usługi Redis .

Aby uzyskać instrukcje dotyczące pobierania narzędzi Redis, zobacz Jak mogę uruchamiać polecenia 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 przetwarza polecenia pojedynczo. Jeśli wydasz KEYS polecenie, usługa Redis nie przetworzy kolejnych poleceń, dopóki nie zakończy przetwarzania KEYS polecenia.

  Witryna redis.io zawiera szczegółowe informacje o złożoności czasowej dla każdej obsługiwanej operacji. Wybierz każde polecenie, aby zobaczyć złożoność każdej operacji.

• Rozmiar kluczy do użycia zależy od scenariusza. Jeśli scenariusz wymaga większych kluczy, możesz dostosować ConnectionTimeoutwartości , a następnie ponowić próbę i dostosować logikę ponawiania prób. Z perspektywy serwera Redis mniejsze wartości kluczy zapewniają lepszą wydajność.

• Te zagadnienia nie oznaczają, że nie można przechowywać większych wartości w usłudze Redis, ale opóźnienia są większe. Jeśli masz jeden zestaw danych, który jest większy niż inny, możesz użyć wielu ConnectionMultiplexer wystąpień, z których każde jest skonfigurowane z innym zestawem wartości limitu czasu i ponawiania prób. Aby uzyskać więcej informacji, zobacz Do czego służą opcje konfiguracji StackExchange.Redis?

Każda warstwa cenowa Azure Cache for Redis ma różne limity połączeń klientów, pamięci i przepustowości. Chociaż każdy rozmiar pamięci podręcznej pozwala na maksymalnie określoną liczbę połączeń, każde połączenie z usługą Redis wiąże się ze skojarzonym obciążeniem. Przykładem takiego obciążenia jest użycie procesora 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 wynikające z obciążenia połączenia oraz obciążenie spowodowane operacjami klienta przekracza pojemność systemu, w pamięci podręcznej mogą wystąpić problemy z pojemnością, nawet jeśli nie zostanie przekroczony limit połączeń dla bieżącego rozmiaru pamięci podręcznej.

Aby uzyskać więcej informacji na temat 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.

• 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 dotyczącej poziomu usług (SLA). Ponadto użyj co najmniej pamięci podręcznej C1 dla środowiska produkcyjnego. Pamięci podręczne C0 są zwykle używane w prostych scenariuszach tworzenia i testowania.
• Należy pamiętać, że Redis jest magazynem danych w pamięci , a w niektórych scenariuszach może dojść do utraty danych. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z utratą danych w Azure Cache for Redis.
• Opracuj swój system tak, aby mógł obsługiwać zakłócenia połączeń spowodowane poprawkami i przełączaniem awaryjnym.
• Korzystaj z wystąpień usługi Azure Redis w warstwie Premium, aby uzyskać większe opóźnienia i przepływność sieci, ponieważ mają one lepszy sprzęt zarówno dla procesora CPU, jak i sieci.

StackExchange.Redis — najlepsze rozwiązania

• Ustaw AbortConnect wartość false, a następnie pozwól na automatyczne ponowne połączenie 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. Na przykład w polu Jaki jest idealny zakres rozmiarów wartości dla redis?, 100 kb jest uważane za duże. Aby uzyskać więcej informacji, zobacz Uwzględnianie większej liczby kluczy i mniejszych wartości.
• Skonfiguruj ustawienia puli wątków, aby uniknąć przekroczenia limitu czasu.
• Użyj wartości domyślnej connectTimeout co najmniej 5 sekund. Ten interwał daje usłudze StackExchange.Redis wystarczający czas na ponowne nawiązanie połączenia, jeśli wystąpi blip sieci.
• Należy pamiętać o kosztach wydajności związanych z różnymi uruchamianymi operacjami. Na przykład KEYS polecenie jest operacją O(n) i należy unikać. Witryna redis.io zawiera szczegółowe informacje na temat złożoności czasowej każdej obsługiwanej operacji. Wybierz każde polecenie, aby zobaczyć złożoność każdej operacji.

Pula wątków środowiska uruchomieniowego języka wspólnego (CLR) ma dwa typy wątków: proces roboczy i port ukończenia we/wy (IOCP).

• WORKER Wątki są używane do takich rzeczy, jak przetwarzanie Task.Run(…)metod lub ThreadPool.QueueUserWorkItem(…) . Różne składniki w CLR również używają tych wątków, gdy praca musi zostać wykonana w wątku w tle.
• IOCP wątki są używane do asynchronicznych operacji we/wy, na przykład podczas odczytu z sieci.

Pula wątków udostępnia nowe wątki robocze lub wątki ukończenia we/wy na żądanie bez żadnego ograniczania przepustowości, dopóki nie osiągnie minimum ustawienia 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 minimum liczbę wątków, pula wątków ogranicza szybkość, z jaką wstrzykuje nowe wątki do jednego wątku na 500 milisekund.

Zazwyczaj, jeśli system otrzymuje serię pracy, która wymaga IOCP wątku, przetwarza to szybko. Jeśli jednak seria jest większa niż skonfigurowane minimum ustawienie, występuje pewne opóźnienie w przetwarzaniu 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ę wolny przez 500 ms, więc tworzony jest nowy wątek.

Zasadniczo, gdy liczba Busy wątków jest większa niż Min liczba wątków, występuje opóźnienie 500 ms, zanim aplikacja przetworzy ruch sieciowy. Ponadto istniejąca nić, która pozostaje bezczynna przez ponad 15 sekund, jest czyszczona, a ten cykl wzrostu i kurczenia się może się powtórzyć.

Komunikaty o błędach z StackExchange.Redis w wersji 1.0.450 lub nowszej drukują statystyki puli wątków, jak pokazano w poniższym przykładzie.

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)

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

Uwaga

StackExchange.Redis może osiągnąć przekroczenie limitu czasu, jeśli wzrost jednego IOCP z wątków lub WORKER jest ograniczony.

Najlepiej ustawić minimalną wartość konfiguracji dla IOCP i WORKER wątków na wartość większą niż wartość domyślna. Nie ma jednego uniwersalnego przewodnika dotyczącego tej wartości, ponieważ właściwa wartość dla jednej aplikacji jest prawdopodobnie zbyt wysoka lub niska dla innej aplikacji. To ustawienie może również wpływać na wydajność innych części skomplikowanych aplikacji. Musisz dostosować to ustawienie do swoich konkretnych potrzeb. Dobrym punktem wyjścia jest 200 lub 300. Następnie przetestuj i dostosuj w razie potrzeby.

Konfigurowanie ustawienia minimalnej liczby wątków

To ustawienie można zmienić programowo przy użyciu metody ThreadPool.SetMinThreads (...) .

Na przykład w NET Framework należy ustawić tę wartość w Global.asax.cs w metodzie Application_Start :

    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);
    }

Jeśli używasz platformy .NET Core, należy ustawić wartość w Program.cs tuż przed wywołaniem :WebApplication.CreateBuilder()

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Uwaga

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

Możliwe jest również określenie ustawienia minimalnej liczby wątków przy użyciu minIoThreadsminWorkerThreads or w elemencie <processModel> konfiguracji w programieMachine.config. Machine.config zwykle znajduje się pod adresem %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Ustawianie minimalnej liczby wątków w ten sposób nie jest zalecane, ponieważ jest to ustawienie obejmujące cały system. Jeśli w ten sposób ustawisz minimalną liczbę wątków, musisz ponownie uruchomić pulę aplikacji.

Uwaga

Wartość określona przez tę metodę jest ustawieniem na rdzeń . Na przykład, jeśli masz komputer czterordzeniowy i chcesz, aby ustawienie minIoThreads wynosiło 200 w czasie wykonywania, użyj <processModel minIoThreads="50">.

Treści powiązane

• Zobacz inne często zadawane pytania dotyczące usługi Azure Cache for Redis.