Часто задаваемые вопросы по управлению кэшем

В этой статье приведены ответы на распространенные вопросы об управлении кэшем Redis для Azure.

Как измерить и протестировать производительность моего кэша?

• Используйте redis-benchmark.exe для нагрузочного тестирования сервера Redis. Используйте его redis-benchmark.exe , чтобы получить представление о возможной пропускной способности перед написанием собственных тестов производительности.
• Используйте redis-cli для мониторинга кэша с помощью INFO команды. Инструкции по загрузке средств Redis см. в разделе Как выполнять команды Redis?
• Если вы используете Transport Layer Security/Secure Socket Layer (TLS/SSL) на экземпляре кэша, добавьте этот --tls параметр в команды инструментов Redis или используйте прокси-сервер, например stunnel для включения TLS/SSL.
• Redis-benchmark По умолчанию используется порт 6379 . Используйте этот -p параметр для переопределения этого параметра, если кэш использует порт 6380 SSL/TLS или порт 10000уровня Enterprise.
• При необходимости вы можете включить порт, отличный от TLS, через портал Azure перед выполнением нагрузочного теста.
• Убедитесь, что клиентская виртуальная машина, используемая для тестирования, находится в том же регионе, что и экземпляр Azure Cache for Redis.
• Убедитесь, что клиентская виртуальная машина имеет по крайней мере такую же вычислительную мощность и пропускную способность, как и тестируемый кэш. Для достижения наилучших результатов используйте виртуальные машины серий D и E для своих клиентов.
• Если вы используете Windows, включите виртуальное масштабирование на стороне приема (VRSS) на клиентском компьютере. Дополнительные сведения см. в статье Виртуальное масштабирование на стороне приема в Windows Server 2012 R2.
• Включите диагностику кэша, чтобы отслеживать его работоспособность. Вы можете просматривать метрики на портале Azure, а также скачивать и просматривать метрики с помощью выбранных вами средств.
• Если нагрузка приводит к высокой фрагментации памяти, увеличьте масштаб до большего размера кэша.

В следующих примерах показано, как использовать redis-benchmark.exe. Для получения точных результатов выполните эти команды с виртуальной машины в том же регионе, что и кэш.

Сначала протестируйте конвейерные SET запросы с использованием полезной нагрузки 1k:

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

После выполнения теста SET выполните конвейерные GET запросы с использованием полезной нагрузки 1k:

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

Как я могу включить сборщик мусора сервера, чтобы получить большую пропускную способность на клиенте при использовании StackExchange.Redis?

Включение сборки мусора сервера (GC) может оптимизировать работу клиента и обеспечить более высокую производительность и пропускную способность при использовании StackExchange.Redis. Дополнительные сведения о сборке мусора сервера и о том, как ее включить, можно найти в следующих статьях:

• Элемент <gcServer>
• Основы сборки мусора
• Сборка мусора и производительность

Следует ли включать порт, отличный от TLS/SSL, для подключения к Redis?

Сервер Redis изначально не поддерживает протокол TLS, но Кэш Azure для Redis поддерживает TLS. Если вы подключаетесь к Кэшу Azure для Redis с помощью клиента, например StackExchange.Redis, который поддерживает TLS, используйте TLS.

Примечание.

Порт, отличный от TLS, по умолчанию отключен для новых экземпляров Azure Redis. Если клиент не поддерживает TLS, включите порт, отличный от TLS, следуя инструкциям в разделе Порты доступа.

Если кэш использует TLS, необходимо включить TLS с помощью параметра --tls для средств Redis, таких как redis-cli. Вы также можете использовать служебную программу, stunnel например для безопасного подключения средств к порту TLS, следуя инструкциям в записи блога Объявление поставщика состояний сеанса для предварительного выпуска Redis ASP.NET .

Инструкции по загрузке средств Redis см. в разделе Как выполнять команды Redis?

Каковы некоторые рекомендации по использованию распространенных команд Redis?

• Избегайте определенных команд Redis, которые выполняются слишком долго, если не до конца понимаете результат этих команд. Например, не запускайте команду KEYS в рабочей среде. В зависимости от числа ключей выполнение может занять много времени. Redis — это однопоточный сервер, который обрабатывает команды по одной. Если вы выполните KEYS команду, Redis не будет обрабатывать последующие команды до тех пор, пока не завершит обработку KEYS команды.

  Сайт redis.io содержит сведения о временной сложности для каждой операции, которую он поддерживает. Щелкните каждую команду, чтобы просмотреть сведения о сложности операции.

• Размер ключей зависит от сценария. Если для вашего сценария требуются ключи большего размера, вы можете настроить ConnectionTimeoutзначения , затем повторить попытку и настроить логику повторных попыток. С точки зрения сервера Redis, меньшие значения ключей обеспечивают более высокую производительность.

• Эти соображения не означают, что вы не можете хранить большие значения в Redis, но задержки выше. Если один набор данных больше другого, можно использовать несколько ConnectionMultiplexer экземпляров, каждый из которых настроен с разным набором значений времени ожидания и повторных попыток. Дополнительные сведения см. в статье Для чего нужны параметры конфигурации StackExchange.Redis?

Каковы некоторые рекомендации по производительности для подключений?

Каждая ценовая категория Кэша Azure для Redis имеет разные ограничения для клиентских подключений, памяти и пропускной способности. Хотя каждый размер кэша допускает до определенного количества подключений, каждое подключение к Redis связано с соответствующими накладными расходами. Примером таких накладных расходов является использование процессора и памяти из-за шифрования TLS/SSL.

Максимальное число подключений для данного размера кэша предполагает низкую загрузку кэша. Если нагрузка от накладных расходов на подключение плюс нагрузка от клиентских операций превышает емкость системы, кэш может испытывать проблемы с емкостью, даже если вы не превышаете ограничение на количество подключений для текущего размера кэша.

Дополнительные сведения об ограничениях подключений для каждого уровня см. в статье Цены на Кэш Azure для Redis. Дополнительные сведения о подключениях и других конфигурациях по умолчанию см. в статье Конфигурация сервера Redis по умолчанию.

Какие рекомендации следует учитывать для рабочей среды?

• Используйте уровень "Стандартный" или "Премиум" для производственных систем. Базовый уровень — это система с одним узлом без репликации данных и соглашения об уровне обслуживания (SLA). Кроме того, используйте как минимум кэш C1 для рабочей среды. Как правило, кэши C0 используются в простых сценариях разработки и тестирования.
• Имейте в виду, что Redis — это хранилище данных в памяти , и в некоторых сценариях может произойти потеря данных. Дополнительные сведения см. в статье Устранение неполадок с потерей данных в Кэше Azure для Redis.
• Разработайте свою систему таким образом, чтобы она могла справляться с перебоями в подключении, вызванными исправлениями и аварийным переключением.
• Используйте экземпляры Azure Redis уровня "Премиум" для снижения задержки и пропускной способности сети, так как они оснащены лучшим оборудованием как для ЦП, так и для сети.

Рекомендации для StackExchange.Redis

• Установите AbortConnect значение false, затем позвольте повторному подключению ConnectionMultiplexer автоматически.
• Используйте один экземпляр ConnectionMultiplexer с длительным сроком действия вместо создания нового подключения для каждого запроса.
• Лучше всего Redis работает с меньшими значениями, поэтому рассмотрите возможность разделения больших данных на несколько ключей. Например, в разделе Каково идеальное значение диапазона размеров для redis?, 100 кб считается большим. Дополнительные сведения см. в разделе Учет большего количества ключей и меньших значений.
• Настройте параметры ThreadPool , чтобы избежать тайм-аутов.
• Используйте по умолчанию не менее connectTimeout 5 секунд. Этот интервал дает StackExchange.Redis достаточно времени для восстановления соединения в случае сбоя в сети.
• Помните о затратах на производительность, связанных с различными выполняемыми операциями. Например, команда KEYS является операцией O(n), т. е. операцией, длительность которой линейно зависит от размера входных данных. Таких операций следует избегать. На сайте redis.io есть подробная информация о временной сложности каждой операции, которую он поддерживает. Щелкните каждую команду, чтобы просмотреть сведения о сложности операции.

Важные сведения о росте ThreadPool

Пул ThreadPool среды CLR имеет два типа потоков: рабочий процесс и порт завершения ввода-вывода (IOCP).

• WORKER Потоки используются для таких вещей, как обработка Task.Run(…)методов , or ThreadPool.QueueUserWorkItem(…) . Различные компоненты среды CLR также используют эти потоки, когда необходимо выполнить работу в фоновом потоке.
• IOCP потоки используются для асинхронного ввода-вывода, например, при чтении из сети.

Пул потоков предоставляет новые рабочие потоки или потоки завершения ввода-вывода по запросу без какого-либо регулирования, пока не будет достигнуто minimum значение для каждого типа потока. По умолчанию минимальное количество потоков равно количеству процессоров в системе.

Как только число существующих занятых потоков достигает minimum числа потоков, ThreadPool регулирует скорость, с которой он внедряет новые потоки, до одного потока в 500 миллисекунд.

Как правило, если в системе происходит всплеск работы, требующий потока IOCP , она быстро обрабатывает эту работу. Однако, если пакет превышает настроенный minimum параметр, возникает некоторая задержка в обработке части работы, так как ThreadPool ожидает одну из двух возможностей:

• Освобождение существующего потока для выполнения работы.
• В течение 500 мс существующий поток не освобождается, поэтому создается новый поток.

В основном, когда количество Busy потоков превышает Min количество потоков, приложение обрабатывает сетевой трафик с задержкой в 500 мс. Кроме того, существующий поток, который простаивает дольше 15 секунд, очищается, и этот цикл роста и сокращения может повториться.

Сообщения об ошибках из сборки StackExchange.Redis 1.0.450 или более поздней версии выводят статистику ThreadPool, как показано в следующем примере.

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)

В примере показано, что для потока IOCP имеется шесть занятых потоков, а система настроена на разрешение четырех минимальных потоков. В этом случае клиент, скорее всего, увидит две задержки по 500 мс, т.к. 6 > 4.

Примечание.

StackExchange.Redis может достигать тайм-аутов, если рост потоков один IOCP или регулируется WORKER вручную.

Лучше всего задать минимальное значение конфигурации для IOCP и WORKER потоков на значение, превышающее значение по умолчанию. Не существует универсального руководства по этому значению, потому что правильное значение для одного приложения, скорее всего, слишком велико или мало для другого приложения. Этот параметр также может повлиять на производительность других частей сложных приложений. Вам необходимо точно настроить эту настройку в соответствии с вашими конкретными потребностями. Хорошей отправной точкой является 200 или 300. Затем протестируйте и настройте по мере необходимости.

Настройка минимального количества потоков

Этот параметр можно изменить программным способом с помощью метода ThreadPool.SetMinThreads (...).

Например, в NET Framework это значение задается в Global.asax.cs в методе 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);
    }

Если вы используете .NET Core, вы устанавливаете значение в Program.cs непосредственно перед вызовом как :WebApplication.CreateBuilder()

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

Примечание.

Значение, указанное этим методом, является глобальным параметром, который влияет на весь AppDomain. Например, если у вас есть четырехядерная виртуальная машина и вы хотите установить minWorkerThreads значение и minIoThreads 50 на ЦП во время выполнения, используйте ThreadPool.SetMinThreads(200, 200).

Также можно указать настройку минимального количества потоков с помощью minIoThreadsminWorkerThreads конфигурации or в <processModel> конфигурации вMachine.config. Machine.config обычно находится по адресу %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Задавать минимальное количество потоков таким образом не рекомендуется, так как это настройка для всей системы. Если таким образом задано минимальное количество потоков, необходимо перезапустить пул приложений.

Примечание.

Значение, указанное этим методом, является параметром для каждого ядра . Например, если у вас четырехядерный компьютер и вы хотите, чтобы во время выполнения было minIoThreads установлено значение 200, используйте <processModel minIoThreads="50">.

Связанный контент

• Ознакомьтесь с другими часто задаваемыми вопросами о Azure Cache for Redis.

В этой статье приведены ответы на распространенные вопросы об управлении кэшем Redis для Azure.

• Используйте redis-benchmark.exe для нагрузочного тестирования сервера Redis. Используйте его redis-benchmark.exe , чтобы получить представление о возможной пропускной способности перед написанием собственных тестов производительности.
• Используйте redis-cli для мониторинга кэша с помощью INFO команды. Инструкции по загрузке средств Redis см. в разделе Как выполнять команды Redis?
• Если вы используете Transport Layer Security/Secure Socket Layer (TLS/SSL) на экземпляре кэша, добавьте этот --tls параметр в команды инструментов Redis или используйте прокси-сервер, например stunnel для включения TLS/SSL.
• Redis-benchmark По умолчанию используется порт 6379 . Используйте этот -p параметр для переопределения этого параметра, если кэш использует порт 6380 SSL/TLS или порт 10000уровня Enterprise.
• При необходимости вы можете включить порт, отличный от TLS, через портал Azure перед выполнением нагрузочного теста.
• Убедитесь, что клиентская виртуальная машина, используемая для тестирования, находится в том же регионе, что и экземпляр Azure Cache for Redis.
• Убедитесь, что клиентская виртуальная машина имеет по крайней мере такую же вычислительную мощность и пропускную способность, как и тестируемый кэш. Для достижения наилучших результатов используйте виртуальные машины серий D и E для своих клиентов.
• Если вы используете Windows, включите виртуальное масштабирование на стороне приема (VRSS) на клиентском компьютере. Дополнительные сведения см. в статье Виртуальное масштабирование на стороне приема в Windows Server 2012 R2.
• Включите диагностику кэша, чтобы отслеживать его работоспособность. Вы можете просматривать метрики на портале Azure, а также скачивать и просматривать метрики с помощью выбранных вами средств.
• Если нагрузка приводит к высокой фрагментации памяти, увеличьте масштаб до большего размера кэша.

В следующих примерах показано, как использовать redis-benchmark.exe. Для получения точных результатов выполните эти команды с виртуальной машины в том же регионе, что и кэш.

Сначала протестируйте конвейерные SET запросы с использованием полезной нагрузки 1k:

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

После выполнения теста SET выполните конвейерные GET запросы с использованием полезной нагрузки 1k:

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

Включение сборки мусора сервера (GC) может оптимизировать работу клиента и обеспечить более высокую производительность и пропускную способность при использовании StackExchange.Redis. Дополнительные сведения о сборке мусора сервера и о том, как ее включить, можно найти в следующих статьях:

• Элемент <gcServer>
• Основы сборки мусора
• Сборка мусора и производительность

Сервер Redis изначально не поддерживает протокол TLS, но Кэш Azure для Redis поддерживает TLS. Если вы подключаетесь к Кэшу Azure для Redis с помощью клиента, например StackExchange.Redis, который поддерживает TLS, используйте TLS.

Примечание.

Порт, отличный от TLS, по умолчанию отключен для новых экземпляров Azure Redis. Если клиент не поддерживает TLS, включите порт, отличный от TLS, следуя инструкциям в разделе Порты доступа.

Если кэш использует TLS, необходимо включить TLS с помощью параметра --tls для средств Redis, таких как redis-cli. Вы также можете использовать служебную программу, stunnel например для безопасного подключения средств к порту TLS, следуя инструкциям в записи блога Объявление поставщика состояний сеанса для предварительного выпуска Redis ASP.NET .

Инструкции по загрузке средств Redis см. в разделе Как выполнять команды Redis?

• Избегайте определенных команд Redis, которые выполняются слишком долго, если не до конца понимаете результат этих команд. Например, не запускайте команду KEYS в рабочей среде. В зависимости от числа ключей выполнение может занять много времени. Redis — это однопоточный сервер, который обрабатывает команды по одной. Если вы выполните KEYS команду, Redis не будет обрабатывать последующие команды до тех пор, пока не завершит обработку KEYS команды.

  Сайт redis.io содержит сведения о временной сложности для каждой операции, которую он поддерживает. Щелкните каждую команду, чтобы просмотреть сведения о сложности операции.

• Размер ключей зависит от сценария. Если для вашего сценария требуются ключи большего размера, вы можете настроить ConnectionTimeoutзначения , затем повторить попытку и настроить логику повторных попыток. С точки зрения сервера Redis, меньшие значения ключей обеспечивают более высокую производительность.

• Эти соображения не означают, что вы не можете хранить большие значения в Redis, но задержки выше. Если один набор данных больше другого, можно использовать несколько ConnectionMultiplexer экземпляров, каждый из которых настроен с разным набором значений времени ожидания и повторных попыток. Дополнительные сведения см. в статье Для чего нужны параметры конфигурации StackExchange.Redis?

Каждая ценовая категория Кэша Azure для Redis имеет разные ограничения для клиентских подключений, памяти и пропускной способности. Хотя каждый размер кэша допускает до определенного количества подключений, каждое подключение к Redis связано с соответствующими накладными расходами. Примером таких накладных расходов является использование процессора и памяти из-за шифрования TLS/SSL.

Максимальное число подключений для данного размера кэша предполагает низкую загрузку кэша. Если нагрузка от накладных расходов на подключение плюс нагрузка от клиентских операций превышает емкость системы, кэш может испытывать проблемы с емкостью, даже если вы не превышаете ограничение на количество подключений для текущего размера кэша.

Дополнительные сведения об ограничениях подключений для каждого уровня см. в статье Цены на Кэш Azure для Redis. Дополнительные сведения о подключениях и других конфигурациях по умолчанию см. в статье Конфигурация сервера Redis по умолчанию.

• Используйте уровень "Стандартный" или "Премиум" для производственных систем. Базовый уровень — это система с одним узлом без репликации данных и соглашения об уровне обслуживания (SLA). Кроме того, используйте как минимум кэш C1 для рабочей среды. Как правило, кэши C0 используются в простых сценариях разработки и тестирования.
• Имейте в виду, что Redis — это хранилище данных в памяти , и в некоторых сценариях может произойти потеря данных. Дополнительные сведения см. в статье Устранение неполадок с потерей данных в Кэше Azure для Redis.
• Разработайте свою систему таким образом, чтобы она могла справляться с перебоями в подключении, вызванными исправлениями и аварийным переключением.
• Используйте экземпляры Azure Redis уровня "Премиум" для снижения задержки и пропускной способности сети, так как они оснащены лучшим оборудованием как для ЦП, так и для сети.

Рекомендации для StackExchange.Redis

• Установите AbortConnect значение false, затем позвольте повторному подключению ConnectionMultiplexer автоматически.
• Используйте один экземпляр ConnectionMultiplexer с длительным сроком действия вместо создания нового подключения для каждого запроса.
• Лучше всего Redis работает с меньшими значениями, поэтому рассмотрите возможность разделения больших данных на несколько ключей. Например, в разделе Каково идеальное значение диапазона размеров для redis?, 100 кб считается большим. Дополнительные сведения см. в разделе Учет большего количества ключей и меньших значений.
• Настройте параметры ThreadPool , чтобы избежать тайм-аутов.
• Используйте по умолчанию не менее connectTimeout 5 секунд. Этот интервал дает StackExchange.Redis достаточно времени для восстановления соединения в случае сбоя в сети.
• Помните о затратах на производительность, связанных с различными выполняемыми операциями. Например, команда KEYS является операцией O(n), т. е. операцией, длительность которой линейно зависит от размера входных данных. Таких операций следует избегать. На сайте redis.io есть подробная информация о временной сложности каждой операции, которую он поддерживает. Щелкните каждую команду, чтобы просмотреть сведения о сложности операции.

Пул ThreadPool среды CLR имеет два типа потоков: рабочий процесс и порт завершения ввода-вывода (IOCP).

• WORKER Потоки используются для таких вещей, как обработка Task.Run(…)методов , or ThreadPool.QueueUserWorkItem(…) . Различные компоненты среды CLR также используют эти потоки, когда необходимо выполнить работу в фоновом потоке.
• IOCP потоки используются для асинхронного ввода-вывода, например, при чтении из сети.

Пул потоков предоставляет новые рабочие потоки или потоки завершения ввода-вывода по запросу без какого-либо регулирования, пока не будет достигнуто minimum значение для каждого типа потока. По умолчанию минимальное количество потоков равно количеству процессоров в системе.

Как только число существующих занятых потоков достигает minimum числа потоков, ThreadPool регулирует скорость, с которой он внедряет новые потоки, до одного потока в 500 миллисекунд.

Как правило, если в системе происходит всплеск работы, требующий потока IOCP , она быстро обрабатывает эту работу. Однако, если пакет превышает настроенный minimum параметр, возникает некоторая задержка в обработке части работы, так как ThreadPool ожидает одну из двух возможностей:

• Освобождение существующего потока для выполнения работы.
• В течение 500 мс существующий поток не освобождается, поэтому создается новый поток.

В основном, когда количество Busy потоков превышает Min количество потоков, приложение обрабатывает сетевой трафик с задержкой в 500 мс. Кроме того, существующий поток, который простаивает дольше 15 секунд, очищается, и этот цикл роста и сокращения может повториться.

Сообщения об ошибках из сборки StackExchange.Redis 1.0.450 или более поздней версии выводят статистику ThreadPool, как показано в следующем примере.

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)

В примере показано, что для потока IOCP имеется шесть занятых потоков, а система настроена на разрешение четырех минимальных потоков. В этом случае клиент, скорее всего, увидит две задержки по 500 мс, т.к. 6 > 4.

Примечание.

StackExchange.Redis может достигать тайм-аутов, если рост потоков один IOCP или регулируется WORKER вручную.

Лучше всего задать минимальное значение конфигурации для IOCP и WORKER потоков на значение, превышающее значение по умолчанию. Не существует универсального руководства по этому значению, потому что правильное значение для одного приложения, скорее всего, слишком велико или мало для другого приложения. Этот параметр также может повлиять на производительность других частей сложных приложений. Вам необходимо точно настроить эту настройку в соответствии с вашими конкретными потребностями. Хорошей отправной точкой является 200 или 300. Затем протестируйте и настройте по мере необходимости.

Настройка минимального количества потоков

Этот параметр можно изменить программным способом с помощью метода ThreadPool.SetMinThreads (...).

Например, в NET Framework это значение задается в Global.asax.cs в методе 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);
    }

Если вы используете .NET Core, вы устанавливаете значение в Program.cs непосредственно перед вызовом как :WebApplication.CreateBuilder()

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

Примечание.

Значение, указанное этим методом, является глобальным параметром, который влияет на весь AppDomain. Например, если у вас есть четырехядерная виртуальная машина и вы хотите установить minWorkerThreads значение и minIoThreads 50 на ЦП во время выполнения, используйте ThreadPool.SetMinThreads(200, 200).

Также можно указать настройку минимального количества потоков с помощью minIoThreadsminWorkerThreads конфигурации or в <processModel> конфигурации вMachine.config. Machine.config обычно находится по адресу %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Задавать минимальное количество потоков таким образом не рекомендуется, так как это настройка для всей системы. Если таким образом задано минимальное количество потоков, необходимо перезапустить пул приложений.

Примечание.

Значение, указанное этим методом, является параметром для каждого ядра . Например, если у вас четырехядерный компьютер и вы хотите, чтобы во время выполнения было minIoThreads установлено значение 200, используйте <processModel minIoThreads="50">.

Связанный контент

• Ознакомьтесь с другими часто задаваемыми вопросами о Azure Cache for Redis.