Очередь запросов IIS внезапно резко возрастает для веб-API ASP.NET Core 8 ⇐ C#

[Anonymous]

Это продолжение моего вопроса
У нас есть веб-API ASP.NET Core 8, который получает большой трафик при полной загрузке, 1500 открытых запросов, 1500 запросов x 30 секунд. , спорадический набор запросов для 1500 клиентов.
Открытые запросы упоминаются в ссылке, которую я разместил выше. По сути, это запрос, который ожидает публикации сообщения в очередь RabbitMQ, которая затем передается обратно клиенту. Запрос «зависает», но поскольку мы провели рефакторинг кода для использования ожиданий, потоки для этих открытых запросов не блокируются.
Вот потребительский код, который у нас есть:

Код: Выделить всё

ncChannel.QueueDeclare(queueName, true, false, false, null);
ncChannel.ExchangeDeclare(ExchangeName, ExchangeType.Topic, true, false, null);
ncChannel.QueueBind(queueName, ExchangeName, routingKey);
Channel responseChannel = Channel.CreateBounded(channelOptions);
EventHandler nextCommandHandler = async (object sender, BasicDeliverEventArgs msg) =>
{
try
{
if (msg != null && msg.Body.ToArray() != null)
{
string msgBody = Encoding.UTF8.GetString(msg.Body.ToArray());
//log
}
else
{
//log
}
await responseChannel.Writer.WriteAsync(msg);
responseChannel.Writer.TryComplete();
}
catch (Exception ex)
{
//log
}
};
consumer.Received += nextCommandHandler;
bool autoAck = true;
consumerTag = ncChannel.BasicConsume(queueName, autoAck, consumer);

CancellationTokenSource timeoutTokenSource = new CancellationTokenSource(55000);

using (CancellationTokenSource linkedToken = CancellationTokenSource.CreateLinkedTokenSource(timeoutTokenSource.Token, HttpContext.RequestAborted))
{
try
{
isMessageFound = await responseChannel.Reader.WaitToReadAsync(linkedToken.Token);

if (isMessageFound)
{
message = await responseChannel.Reader.ReadAsync();
//log; cancel consumer
}
else
{
//log
}
}
catch (OperationCanceledException)
{
isMessageFound = false;

if (timeoutTokenSource.IsCancellationRequested)
{
//log timeout
}
}
}

Клиент RabbititMQ 6.8.1 имеет известную проблему неправильного управления потоками, и изначально мы думали, что проблема именно в этом. Предполагалось, что эту проблему можно решить, установив для значения ThreadPool.MinThreads соответствующее значение, чтобы уменьшить зависания, вызванные клиентом. Однако, похоже, это только маскирует проблему, поскольку, когда у нас есть развертывание, в котором база данных находится на другом сервере, сбой кажется лишь вопросом времени, независимо от того, какое значение мы установили для MinThreads.
Мы добавили код, чтобы попытаться определить, когда и как происходит исчерпание потоков, поскольку мы замечаем симптом, заключающийся в том, что очереди запросов внезапно растут до тех пор, пока пул приложений не выйдет из строя. При чтении онлайн рост очереди запросов вызван исчерпанием потоков. Мы добавили ведение журнала, чтобы показать текущие доступные потоки, и все, что мы видим, это то, что всплеск очереди запросов происходит очень внезапно, никакого накопления не обнаружено.
Что нам действительно нужно, так это направление, чтобы проверьте, мы проверили код, средство просмотра событий, другие журналы, чтобы попытаться выяснить, что вызывает всплеск, но мы не можем ничего найти. Мы будем очень признательны за любую помощь.
Мы уже рассматривали возможность изменения архитектуры для использования веб-сокетов, однако наши клиенты представляют собой аппаратные устройства, которые невозможно легко обновить, поэтому мы застряли. необходимо заставить это работать до тех пор, пока устройства не будут обновлены.
Я наметил 2 разных запуска с доступной записью потоков и вот несколько снимков экрана.



Подробнее здесь: https://stackoverflow.com/questions/791 ... -8-web-api