Контекст: у меня есть 2 приложения, оба публикуются на одном и том же сервере RabbitMQ, разные очереди, но очереди настроены одинаково, поэтому я не буду вдаваться в подробности их конфигураций.
Оба отправляют сообщения одинаково. У меня настроен массовый транзит при запуске, я использую ISendEndpointProvider, чтобы получить конечную точку отправки, а затем отправить сообщение. Каждая из этих очередей используется разными потребителями, потребители живут в другом приложении, но оба находятся в одном приложении. Опять же, конфигурация массового транспорта одинакова для обоих.
Консольное приложение фоновых процессов:
- hangfire создает задания;
- каждое задание получает некоторые данные и начинает помещать все данные в одну и ту же очередь.
- Операция отправки занимает в среднем 20–40 мс, есть пики, но они случайны и не выходят за рамки 300-400 мс
- объемы, которые эти задания ставят в очередь, в среднем в 3 раза превышают объем, который API должен поставить в очередь в любой момент времени
- 1 конечная точка
- для каждого запроса, я просто беру сообщение и отправляю его в очередь, вот и все. all
- И вот здесь становится круто. В определенные интервалы времени среднее время, необходимое для завершения операции отправки, превышает 10 000 мс. А когда идет дождь, это влияет на все операции отправки в API.
- я не могу связать это с количеством получаемых запросов, я зарегистрировал одинаковое количество запросов в разные моменты времени, иногда операция отправки занимает много времени, иногда она занимает в среднем 20-40 мс -> поэтому я на самом деле не могу связать его с пулом потоков, параллелизмом или каким-либо истощением, но, пожалуйста, скажите мне, если вы думаете, что это может быть виновником
- если оно исходит от сервера RabbitMQ, я не понимаю, почему консольное приложение не страдает, когда оно публикует больше сообщений. и с сервером, кажется, все в порядке.
Подробнее здесь: https://stackoverflow.com/questions/798 ... lly-slowly
