Тайм-ауты и медленные запросы к Redis при использовании библиотеки StackExchange.Redis - PullRequest
Новая
       37

Тайм-ауты и медленные запросы к Redis при использовании библиотеки StackExchange.Redis

0 голосов
/ 03 декабря 2018

Мы начали использовать Redis в нашем приложении, чтобы сохранять там ответы API.Я решил использовать StackExchange.Redis для работы с ним, и после реализации всей логики сохранения ответов результаты стресс-тестирования стали весьма разочаровывающими.Общая пропускная способность приложения снизилась в 3-4 раза!Это было около 550-600rps, а сейчас около 180rps (и может быть даже медленнее).

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

Timeout awaiting response (5094ms elapsed, timeout is 5000ms), inst: 0, qs: 10, in: 65536, mgr: 10 of 10 available, IOCP: (Busy=26,Free=974,Min=8,Max=1000), WORKER: (Busy=3,Free=32764,Min=8,Max=32767), v: 2.0.513.63329 
Timeout awaiting response (5063ms elapsed, timeout is 5000ms), inst: 0, qs: 4, in: 47355, mgr: 10 of 10 available, IOCP: (Busy=40,Free=960,Min=8,Max=1000), WORKER: (Busy=34,Free=32733,Min=8,Max=32767), v: 2.0.513.63329 
The timeout was reached before the message could be written to the output buffer, and it was not sent (5000ms, inst=3, qs=3, in=10, active=HMSET), inst: 3, qs: 3, in: 10, mgr: 10 of 10 available, IOCP: (Busy=36,Free=964,Min=8,Max=1000), WORKER: (Busy=34,Free=32733,Min=8,Max=32767), v: 2.0.513.63329

А вот общая обзорная картина всех исключений тайм-аутовпроизошел во время последнего стресс-теста: Statistics

Я пытался реализовать пул соединений (на основе свойства TotalOutstanding), пытался уменьшить количество запросов к Redis и т. д., ноэто не помогло

Я выполнил команды SHOW LOG и LATENCY DOCTOR, но похоже, что с нашим экземпляром Redis все в порядке (хотя мы отключили THP, как это было рекомендовано врачом).

Мое предположениечто некоторые очень большие ответы API препятствуют выполнению других запросов.Я так думаю из-за высоких значений входящего трафика.Это правильно?Что можно сделать с этим?Нужно ли как-то разделять запросы?

1 Ответ

0 голосов
/ 03 декабря 2018

Я вижу здесь интересную подсказку: 

The timeout was reached before the message could be written to the output buffer

Я думаю, что в основном Redis говорит вам убрать входящее сообщение, потому что это фальсифицирует данные для вас.Скорее всего, вы создали довольно широкую подписку.

Я прошел через тот же опыт и закончил тем, что просто поместил данные в кэш памяти (aka ConcurrentQueue<T>) в лямбде подписки, и обработал результаты сообщения в отдельном, удушенном потоке, которыйпроверить очередь и обработать содержимое, типичный подход производитель-потребитель-очередь.Ошибки тайм-аута исчезли в этот момент.

...