Кэш Redis для Azure: часто задаваемые вопросы

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

Инструменты Redis, такие как redis-cli, не работают с портом TLS, но вы можете использовать служебную программу, например stunnel, для безопасного подключения инструментов к порту TLS в соответствии с указаниями в записи блога Анонс поставщика состояний сеансов ASP.NET для предварительной версии Redis.

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

• Рекомендации для StackExchange.Redis
• Конфигурация и основные понятия
• Тестирование производительности

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

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

Конфигурация и основные понятия

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

Тестирование производительности

• Начните с запуска redis-benchmark.exe , чтобы определить возможную пропускную способность перед созданием собственных тестов производительности. Так как redis-benchmark не поддерживает протокол TLS, перед запуском теста необходимо включить порт без TLS на портале Azure. Примеры приведены в разделе Как измерить и протестировать производительность моего кэша?
• Клиентская виртуальная машина, используемая для тестирования, должна находиться в том же регионе, что и экземпляр кэша Azure для Redis.
• В качестве клиента рекомендуется использовать виртуальные машины серии Dv2, так как в них используется более производительное оборудование и они выдают лучшие результаты.
• Убедитесь, что у выбранной клиентской виртуальной машины как минимум такая же емкость вычислительных ресурсов и пропускная способность, что и у тестируемого кэша.
• Включите VRSS на клиентском компьютере, если используется среда Windows. Щелкните здесь, чтобы узнать больше.
• Экземпляры Redis уровня "Премиум" обеспечивают меньшие сетевые задержки и большую пропускную способность, так как используют более производительные ЦП и сетевое оборудование.

• Избегайте определенных команд Redis, которые выполняются слишком долго, если не до конца понимаете результат этих команд. Например, не запускайте команду KEYS в рабочей среде. В зависимости от числа ключей выполнение может занять много времени. Redis является однопотоковым сервером и обрабатывает команды по одной. Если вы выдадите после KEYS другие команды, они не будут обрабатываться, пока Redis обрабатывает команду KEYS. Сайт redis.io содержит сведения о временной сложности каждой поддерживаемой операции. Щелкните каждую команду, чтобы просмотреть сведения о сложности операции.
• Размеры ключей — следует использовать пары "ключ-значение" небольшого или большого размера? Это зависит от сценария развертывания. Если в сценарии требуются большие ключи, то можно настроить значения повторов и ConnectionTimeout, а также настроить логику повторов. С точки зрения сервера Redis чем меньше значения, тем выше производительность.
• Это не означает, что в Redis нельзя хранить большие значения; вы должны учитывать описанные ниже факторы. Задержки будут выше. Если один из используемых наборов данных больше, а другой меньше, можно использовать несколько экземпляров ConnectionMultiplexer. Настройте для каждого из них свои значения времени ожидания и повтора, как описано в предыдущем разделе: Что делают параметры конфигурации StackExchange.Redis?

• Включите диагностику кэша, чтобы можно было наблюдать за работоспособностью кэша. Вы можете просмотреть метрики на портале Azure. Кроме того, их можно скачать и просмотреть с помощью привычных вам инструментов.
• Для нагрузочного теста сервера Redis можно использовать benchmark.exe.
• Убедитесь, что клиент нагрузочного тестирования и кэш Azure для Redis находятся в одном регионе.
• Используйте redis-cli.exe и наблюдайте за кэшем с помощью команды INFO.
• Если ваша нагрузка приводит к высокой степени фрагментации памяти, то необходимо масштабирование до большего размера кэша.
• Инструкции по скачиванию инструментов Redis см. в разделе Как выполнять команды Redis?.

Ниже приведены некоторые примеры использования redis-benchmark.exe. Чтобы получить точные результаты, выполните эти команды на виртуальной машине, размещенной в том же регионе, что и кэш.cache-development-faq.yml.

• Тестирование конвейерных запросов SET с полезными данными размером в 1 КБ.

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

• Тестирование конвейерных запросов GET с полезными данными размером в 1 КБ.

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

В CLR ThreadPool существует два типа потоков — "Рабочий поток" и "Порт завершения ввода-вывода" (IOCP).

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

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

Когда количество существующих (занятых) потоков достигает "минимального" количества потоков, ThreadPool изменяет частоту внедрения новых потоков до величины в один поток за 500 миллисекунд. Как правило, если нагрузка системы достигает величины, для которой необходим поток IOCP, то эта работа будет сделана быстро. Однако, если величина нагрузки больше настроенного параметра "Минимум", при обработке некоторых операций возникнет задержка, так как ThreadPool будет ожидать возникновения одного из двух событий.

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

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

Если взглянуть на пример сообщения об ошибке от StackExchange.Redis (сборка 1.0.450 или более поздней версии), мы увидим, что теперь оно содержит статистику ThreadPool. Сведения о потоках IOCP и рабочих потоках представлены далее.

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 так, чтобы оно превышало значение по умолчанию. Мы не можем дать универсальных рекомендаций для этого значения, так как подходящее значение для одного приложения будет слишком высоким или низким для другого. Этот параметр также может повлиять на производительность других компонентов сложных приложений, поэтому каждый клиент должен точно настроить этот параметр в соответствии со своими потребностями. Хорошей отправной точкой является 200 или 300, после чего нужно проверить и изменить этот параметр в соответствии с результатом.

Как настроить этот параметр:

• Рекомендуется изменить этот параметр программно с помощью метода ThreadPool.SetMinThreads (...) в global.asax.cs. Рассмотрим пример.

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

  Примечание.

  Значение, указанное в этом методе, — это глобальный параметр, который влияет на весь домен приложения. Например, если у вас 4-ядерный компьютер и вам нужно установить для параметров minWorkerThreads и minIOThreads значение 50 на ЦП во время выполнения, используется ThreadPool.SetMinThreads (200, 200).

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

  Примечание.

  В этом элементе конфигурации задается параметр per-core. Например, если у вас 4-ядерный компьютер и вы хотите установить для параметра minIOThreads значение 200 во время выполнения, то можно использовать <processModel minIoThreads="50"/>.

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

• Включение сборки мусора сервера
• Основные сведения о сборке мусора
• Сборка мусора и производительность

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

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

Следующие шаги

Узнайте о других часто задаваемых вопросах про кэш Redis для Azure.