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

Для приложения .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, но все равно получаю те же результаты.


amazon-ec2 asp.net-core iis kestrel jmeter
person Sergey Nikitin    schedule 15.05.2019    source источник
comment
что настроено для Kestrel MaxConcurrentConnections? у вас есть максимальное соединение в MSSQL? можете ли вы протестировать конечную точку без использования базы данных?   -  person user7294900    schedule 15.05.2019
comment
@ user7294900, номера одновременных подключений MaxConcurrentConnections и MSSQL не заданы. Я только что запустил тест на другой конечной точке (читает некоторую информацию из кеша) - разрыв в производительности был еще больше.   -  person Sergey Nikitin    schedule 15.05.2019
comment
Это действительно странно, потому что IIS - это, по сути, просто обратный прокси перед Kestrel, но когда вы размещаете на IIS, у вас в любом случае должна быть запущена полная пустельга. См. docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/   -  person Daboul    schedule 15.05.2019
comment
Рассмотрим weblog.west -wind.com/posts/2017/mar/16/ и weblog.west-wind.com/posts/2019/Mar/16/   -  person Lex Li    schedule 15.05.2019
comment
Спасибо за ссылки, я пробовал nginx + Kestrel в Windows, и производительность была хорошей. Кажется, у меня низкая производительность Kestrel только на Linux (в частности, AWS ECS).   -  person Sergey Nikitin    schedule 16.05.2019
comment
@SergeyNikitinI У меня тоже ситуация с худшей производительностью ECS (Fargate) по сравнению с IIS / Windows. Вы нашли какие-нибудь решения для повышения производительности?   -  person mbp    schedule 20.05.2019
comment
@mbp Я все еще пытаюсь определить основную проблему, но похоже, что это какая-то ошибка в нашем приложении. У нас есть некоторые подсказки, которые могут быть вызваны промежуточным программным обеспечением или фоновыми процессами. Поделюсь любыми обновлениями.   -  person Sergey Nikitin    schedule 20.05.2019
comment
@mbp Я приступил к устранению проблем с производительностью ECS - теперь, когда мы перешли от синхронизации к асинхронным контроллерам, производительность контейнера 1 близка к экземпляру EC2. Далее, возникает проблема масштабируемости - 2 контейнера все еще лучше, а 4 - намного хуже. Основная причина здесь - алгоритмы балансировки нагрузки, похоже, конфликтуют с алгоритмом внедрения потоков среды CLR. Похоже, установка разогретого пула потоков с помощью ThreadPool.SetMinThreads (100, 100) перед BuildWebHost в Main () - это быстрый взлом, но я все еще занимаюсь исследованием.   -  person Sergey Nikitin    schedule 23.05.2019
comment
Спасибо за ваш ответ @SergeyNikitin. Я обнаружил, что .NET Core на ECS / Linux гораздо более чувствителен к производительности, чем его аналог EC2 / Windows. Небольшие задержки в запросах могут быстро привести к тому, что сервер перестанет отвечать, либо из-за нехватки потоков, либо из-за использования всего ЦП. Надеясь, что 3.0 сделает эти вещи лучше.   -  person mbp    schedule 24.05.2019
comment
Я хочу добавить, что наши проблемы с производительностью были вызваны использованием Fargate вместо ECS / EC2. В Fargate вы не знаете, какой базовый тип экземпляра работает. Работа нашего приложения на инстансах c5 в ECS / EC2 вместо Fargate существенно изменила ситуацию.   -  person mbp    schedule 16.06.2019
comment
@mbp Мы также переходим на ECS / EC2 (из-за необходимости общего постоянного хранилища EFS). Я поделюсь результатами новых тестов производительности, как только мы полностью перейдем на EC2.   -  person Sergey Nikitin    schedule 17.06.2019
comment
@mbp btw, я пробовал 3.0 / 3.1 с этим проектом, и на самом деле он был на 15-25% быстрее. Кроме того, управляемые ресурсы ECS / EC2 с большим количеством ЦП позволили получить больше запросов в секунду. С тех пор я также пробовал различные инструменты нагрузочного тестирования, и лучшим вариантом было выполнение на выделенном сервере внутри того же vpc.   -  person Sergey Nikitin    schedule 20.02.2020

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

Ссылки:

person Sergey Nikitin    schedule 21.05.2019