В этом посте не будет кода, и на данном этапе мы ищем общую информацию, которая может быть у кого-то, но которая у нас отсутствует.
У нас есть поисковая система с потоком c трафика как: Вызов API с параметрами поиска (от клиентов со всего мира) -> Конечная точка API как служба веб-приложения Azure, на которой работает. NET Core 3.1 -> микросервис в Azure Service Fabri c Cluster (. NET Framework 4.7) -> ElasticSearch.
Сегодня мы выполнили запланированное обновление, чтобы обновить микросервис до. NET Core 3.1. После развертывания мы немедленно начали получать периодические 500 внутренних ошибок сервера при вызове API с сообщением «Задача была завершена преждевременно», что, похоже, все указывает на то, что микросервис не может справиться с нагрузкой.
Затем мы откатились до. NET версии Framework, и все вернулось к норме.
Мы были уверены. NET Core 3.1 собирался значительно превзойти версию службы. NET Framework, особенно после просмотра что наше обновление для службы веб-приложений API от Framework до Core значительно улучшило пропускную способность. Но похоже, что произошло обратное.
Мы все еще находимся на ранних стадиях дополнительных испытаний и диагностики, но это вопрос, который я хотел задать прямо сейчас: в сценарии вышеупомянутого типа, знает ли кто-нибудь о все очевидное, что мы могли бы упустить в нашем. NET основном коде, учитывая, что наш подход заключался в том, чтобы взять исходный код микросервиса, обновить целевую платформу, обновить любые ошибки и предупреждения, возникающие в результате этого, убедитесь, что все наши ссылки nuget находятся в очереди и развертываются.
То, что я потенциально ищу здесь, это что-нибудь вроде «для обработки HTTP-запросов в Service Fabri c микросервисов на. NET Core, вы также хотел бы убедиться, что в новом коде есть .... "
Я понимаю, что это немного общий вопрос и без предложенного кода, но четверо из нас" под прицелом "в момент, и я подумал, что не помешает понять, упускаем ли мы то, что обычно упускают, или что кто-то испытал как сценарий ios с.