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

• Используйте 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, необходимо включить TLS с помощью параметра --tls для средств Redis, таких как redis-cli. Вы также можете использовать такую утилиту, как stunnel, например, для безопасного подключения инструментов к порту TLS, следуя инструкциям в блоге Анонс предварительной версии поставщика состояний сеанса 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 Cache для Redis.
• Разработайте свою систему таким образом, чтобы она могла справляться с перебоями в подключении, вызванными исправлениями и аварийным переключением.
• Используйте экземпляры Azure Redis уровня "Премиум" для снижения задержки и пропускной способности сети, так как они оснащены лучшим оборудованием как для ЦП, так и для сети.

Лучшие практики для StackExchange.Redis

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

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

• WORKER Потоки используются для таких задач, как обработка Task.Run(…), или 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.

Лучше всего задать минимальное значение конфигурации для 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

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

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

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

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