Kestrel против IIS + производительность Kestrel (пропускная способность) с использованием .NET Core 2.2

Question

Для приложения .NET Core 2.2, развернутого на одном хосте AWS EC2, я сравниваю хостинг IIS с обычным хостингом Kestrel.

Для конфигурации IIS я следовал документации MS .

Для Kestrel я просто использовал:

dotnet app.dll --server.urls http://*:5000

Я провожу «стрессовый» тест с JMeter для сравнения пропускной способности.Этот тест просто вызывает конечную точку приложения со 100 потоками в течение 10 секунд (разогрев 5 секунд).Обратите внимание, что конечная точка в основном получает одни и те же данные из базы данных MSSQL Server при каждом вызове, без кэширования и т. Д.

В результате Kestrel не выполняет 75% запросов с закрытыми сокетами / ошибками тайм-аута:

ВОПРОС: Какая ошибка конфигурации может привести к такому поведению Kestrel?Я пытался использовать базовый обратный прокси-сервер nginx перед Kestrel, но все равно получал те же результаты.

Answer 1

Оказалось, что описанное поведение возникает при тестировании производительности синхронной конечной точки.

Следуя алгоритму Внедрение потока , CLR будет иметь только minWorkerThreads / minIoThreadsдля обработки запросов, и поскольку в «стрессовом» тесте используется больше потоков, чем создано, мы ожидаем новых потоков, что приводит к почти линейному увеличению времени отклика.

Переключение на асинхронный устраняетразница в производительности, см .:

Ссылки:

• ASP.NET MVC и Web API - Сравнениеасинхронных / синхронизирующих действий
• Официальные документы по CLR Внедрение потока алгоритм
• Связанные проблемы SO