Тайм-аут Azure Redis с несколькими экземплярами веб-приложения Azure

Question

Я использую Redis-клиент StackExchange для чтения и записи данных в Azure Cache (C2). Во время нагрузочного тестирования, если я использую один экземпляр веб-приложения, Redis работает нормально, без каких-либо ошибок. Однако, если я установил несколько экземпляров веб-приложения (пробовал 5 экземпляров с автоматическим масштабированием и без него), я получаю следующую ошибку

Timeout performing GET {key}, inst: 2, mgr: Inactive, err: never, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: {client}, serverEndpoint: Unspecified/{redis_server}, keyHashSlot: 13746, IOCP: (Busy=1,Free=999,Min=4,Max=1000), WORKER: (Busy=26,Free=32741,Min=4,Max=32767) (Please take a look at this article for some common client-side issues that can cause timeouts: http://stackexchange.github.io/StackExchange.Redis/Timeouts)

Я пытался увеличить IOCP а также WORKER а также для проекта MVC, который показывает правильное Min значения, но все равно выдает ошибку.

Бревно с увеличенной резьбой выглядит как ниже

Timeout performing GET {key}, inst: 6, mgr: Inactive, err: never, queue: 1, qu: 0, qs: 1, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: {client}, serverEndpoint: Unspecified/{redis_server}, keyHashSlot: 13746, IOCP: (Busy=2,Free=998,Min=100,Max=1000), WORKER: (Busy=84,Free=32683,Min=200,Max=32767) (Please take a look at this article for some common client-side issues that can cause timeouts: http://stackexchange.github.io/StackExchange.Redis/Timeouts)

Любое предложение, что может быть причиной этого?

Answer 1

[Изменено]

Первая ошибка показала, что изменения в ThreadPool не вступили в силу. Однако обновленное сообщение об ошибке, которое вы недавно опубликовали, показывает, что они вступили в силу, и это хорошо.

Теперь, когда вы исправили эту проблему, вероятно, есть другие проблемы, которые вызывают длительные тайм-ауты. Я задокументировал наиболее распространенные причины здесь:

Проблемы со стороны клиента

Проблемы на стороне сервера

Один из других распространенных, которые я вижу, - это то, что процессор на стороне клиента достигает 100%. Вы должны быть осторожны, чтобы смотреть на MAX CPU, а не на AVG CPU, потому что AVG CPU может быть меньше 100%, в то время как MAX все еще достигает 100%. Всякий раз, когда процессор достигает 100%, у вас не хватает вычислительной мощности, и будут задержки в обработке ответов, отправленных сервером (даже если сервер ответил очень быстро).