Изменить

Поделиться через

Часто задаваемые вопросы об управлении Управляемыми Redis (предварительная версия) Azure

  • Вопросы и ответы

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

Когда следует включать порт, не являющийся портом TLS/SSL, для подключения к Redis?

Использование TLS рекомендуется в качестве рекомендации практически во всех вариантах использования Redis. Параметр подключения без TLS включен для обеспечения обратной совместимости.

Примечание.

Порт, отличный от TLS, отключен по умолчанию для новых экземпляров Управляемого Redis (предварительная версия) Azure. Если клиент не поддерживает TLS, необходимо включить порт, отличный от TLS, следуя указаниям в разделе "Порты Access" статьи "Настройка кэша в Управляемом Redis Azure".

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

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

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

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

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

Какие факторы следует учитывать при использовании общих команд Redis?

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

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

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

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

Примечание.

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

Рекомендация

С учетом этой информации мы настоятельно рекомендуем клиентам устанавливать значение параметра "Минимум" для рабочих потоков и потоков 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);
}

    Примечание.

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

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

    Примечание.

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

Включение GC сервера для получения дополнительной пропускной способности на клиенте при использовании StackExchange.Redis

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

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

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

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

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

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