RedisTimeoutException при нагрузочном тестировании ASP. NET веб-приложения, использующего провайдер состояния сеанса Redis - PullRequest
Новая
       74

RedisTimeoutException при нагрузочном тестировании ASP. NET веб-приложения, использующего провайдер состояния сеанса Redis

0 голосов
/ 02 апреля 2020

Я нагрузочно тестирую веб-приложение ASP. NET, которое использует провайдер состояния сеанса Redis , который использует StackExchange.Redis . Сайт размещен на виртуальных машинах в Azure с 3 серверами за балансировщиком нагрузки Azure и использует премиальный Azure кэш для службы Redis. Когда мы тестируем его с большой нагрузкой (1000 виртуальных пользователей), мы видим некоторые ошибки, подобные этой:

RedisTimeoutException: истекло время ожидания, прежде чем сообщение могло быть записано в выходной буфер, и оно не было отправлено (5000 мс, inst = 637, qs = 23, in = 0, active = EVAL), inst: 637, qs: 23, in: 0, serverEndpoint: не указано / ******. redis.cache. windows. net: 6380, мгр: 10 из 10 доступных, clientName: ProdWeb1, IOCP: (занят = 0, свободен = 1000, мин = 8, макс = 1000), РАБОЧИЙ: (занят = 210, свободен = 32557, Мин. = 8, Макс. = 32767), v: 2.0.519.65453 (Ознакомьтесь с этой статьей, чтобы узнать о некоторых типичных проблемах на стороне клиента, которые могут привести к тайм-аутам: https://stackexchange.github.io/StackExchange.Redis/Timeouts)

он также регистрирует следующие связанные значения: 

{
  "Redis-Message": "EVAL",
  "Redis-Instantaneous": "637",
  "Redis-Queue-Awaiting-Response": "23",
  "Redis-Inbound-Bytes": "0",
  "Redis-Server-Endpoint": "Unspecified/******.redis.cache.windows.net:6380",
  "Redis-Manager": "10 of 10 available",
  "Redis-Client-Name": "ProdWeb1",
  "Redis-ThreadPool-IO-Completion": "(Busy=0,Free=1000,Min=8,Max=1000)",
  "Redis-ThreadPool-Workers": "(Busy=210,Free=32557,Min=8,Max=32767)",
  "Redis-Busy-Workers": "210",
  "Redis-Version": "2.0.519.65453",
  "redis-command": "EVAL",
  "request-sent-status": "WaitingToBeSent",
  "redis-server": "******.redis.cache.windows.net:6380",
}

Я не совсем уверен, как это интерпретировать, но я думаю, потому что Busy меньше, чем Free как для ThreadPool-IO-Completion, так и для ThreadPool -Работники, странно иметь тайм-аут. Использование ЦП и памяти неплохое, поэтому я подозреваю, что, возможно, оно достигает предела для сетевых подключений, но не знаю, как это исследовать.

...