Почему Azure Redis Cache на asp.net использует только несколько подключенных клиентов из 1000 и выдает ошибку тайм-аута?

В последние дни я пытаюсь оптимизировать свой веб-сайт из-за низкой производительности, вызванной кешем Redis, когда у меня пик подключения.

Я использую Redis версии 1.2.6 и установил abortConnect=false в строке подключения.

вот как я могу подключиться к Redis:

private static readonly Lazy<ConnectionMultiplexer> LazyConnection
  = new Lazy<ConnectionMultiplexer>(() => 
ConnectionMultiplexer.Connect(GetRedisConnectionString()));

private static readonly Lazy<ConnectionMultiplexer> LazyConnection
  = new Lazy<ConnectionMultiplexer>(() =>
  {
      var connection = ConnectionMultiplexer.Connect(GetRedisConnectionString());
      connection.PreserveAsyncOrder = false;
      //connection.TimeoutMilliseconds
      return connection;
  });

В global.asax я изменил минимальные потоки, как это предлагается в этой статье http://stackexchange.github.io/StackExchange.Redis/Timeouts

    int workerThreads = 500;
    int iocpThreads = 500;

    System.Threading.ThreadPool.SetMinThreads(workerThreads, iocpThreads)

Но у нас все еще есть ошибка, подобная этой, в журнале:

Timeout performing GET campaign_url_728566_288, inst: 19, mgr: Inactive, 
err: never, queue: 7, qu: 0, qs: 7, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, 
clientName: RD00155D881345, serverEndpoint: 
Unspecified/**********************, keyHashSlot: 6859, IOCP: 
(Busy=0,Free=1000,Min=500,Max=1000), WORKER: 
(Busy=25,Free=8166,Min=500,Max=8191)

or

Timeout performing GET campaign_url_728566_288, inst: 7, mgr: Inactive, err: 
never, queue: 24, qu: 0, qs: 24, qc: 0, wr: 0, wq: 0, in: 4488, ar: 0, 
clientName: RD00155D881345, serverEndpoint: Unspecified**********, 
keyHashSlot: 6859, IOCP: (Busy=0,Free=1000,Min=500,Max=1000), WORKER: 
(Busy=40,Free=8151,Min=500,Max=8191)

Теперь я заметил, что максимальное количество подключений, созданных и отображаемых на портале, составляет не более 20, хотя я ожидаю, что их будет больше во время большого объема. соединение Azure Redis

Есть ли какие-либо настройки для увеличения количества подключений от ConnectionMultiplexer? Или проблема связана с размером кэша (в настоящее время стандарта C1) или из-за ограниченной пропускной способности?


person Riccardo    schedule 08.01.2018    source источник


Ответы (1)


Такие проблемы могут быть вызваны проблемами на стороне сервера или клиента. Вы заглядывали в https://gist.github.com/JonCole/db0e90bedeb3fc4823c2#file-diagnoserediserrors-clientside-md и https://gist.github.com/JonCole/9225f783a40564c9879d#file-diagnoserediserrors-serverside-md?

Если вы отправите нам следующую информацию (https://gist.github.com/JonCole/132b255425268459ec95#file-supportquestionnaire-md) по адресу [email protected], мы также можем выяснить, есть ли какие-либо узкие места на сервере, и какие рекомендации мы можем дать.

person Carl Dacosta    schedule 09.01.2018
comment
Наличие большего количества подключений может не исправить ваши ошибки тайм-аута — это будет зависеть от фактической причины тайм-аута. Документы, на которые ссылается Карл, описывают наиболее распространенные причины тайм-аутов. Учитывая, что StackExchange.Redis поддерживает конвейерную обработку, обычно не требуется увеличивать количество подключений, чтобы получить хорошую пропускную способность. StackExchange.Redis не использует тайный пул соединений. Однако, если вы хотите попробовать добавить больше подключений, вы можете сделать это, создав пул объектов ConnectionMultiplexer, а затем распределив запросы по разным мультиплексорам. - person JonCole; 09.01.2018
comment
Это определенно была проблема, связанная с клиентом ЦП, который достигает 100%. Мы переходим от 20 запросов/сек к 500 запросам/сек. Одна душа - горизонтально масштабировать нашего клиента. Считаете ли вы, что сокращение времени ожидания с 5000 до 500 мс-1 сек будет хорошей идеей для оптимизации (учитывайте, что страница используется для отслеживания кликов и последующего перенаправления на ссылку, хранящуюся в Redis)? - person Riccardo; 12.01.2018
comment
Для небольших значений данных размером до 1 КБ или чуть больше обычно достаточно тайм-аута в 1 секунду. Это также значение по умолчанию. Установка его ниже 1 секунды не означает, что запросы будут выполняться раньше, даже если большинство запросов должны выполняться намного раньше. Таким образом, если оно составляет около 1 секунды, это должно помочь вам в ситуации, когда сбой сети или что-то еще приводит к тому, что один запрос занимает больше времени и время ожидания. Кроме того, убедитесь, что вы обычно работаете где-то, скажем, на 50% ЦП, поэтому есть место для всплесков ЦП, то же самое для пула потоков. - person Carl Dacosta; 13.01.2018