Почему ASP.NET Приложение Такое Медленное? 10 Проблем с Производительностью и Их Решения. Окончание
Начало (1)
Продолжение (2-4)
Продолжение (5-7)
8. Сбои сервера
Как и зависания запросов, сбои сервера могут проявляться как проблемы с производительностью. Когда во время запроса происходит обычное исключение, приложение не вылетает. Сервер возвращает ответ об ошибке 500, и всё продолжается как обычно. Но сбой может произойти, если исключение случится вне контекста запроса, например, в потоке, который вы запустили сами. Помимо этого, существуют катастрофические исключения, такие как
OutOfMemoryException, ExecutionEngineException и моё любимое StackOverflowException. Они приводят к сбою процесса независимо от того, сколько блоков catch вы разместите.Когда приложение ASP.NET, размещённое в IIS, даёт сбой, сервер временно отключается. IIS выполняет перезапуск пула приложений, который перезапустит ваш сервер и вернётся к обычному режиму работы. Последствием для клиента будут временные медленные ответы или ошибки 503.
В зависимости от вашего приложения один сбой может не быть концом света, но повторяющиеся сбои сильно замедлят работу сервера, скрывая настоящую причину под проблемой с производительностью. Решением этой проблемы, конечно же, является устранение основной причины сбоя.
9. Чрезмерная функциональность для каждого запроса
Довольно часто ваши запросы украшают дополнительными функциями. Они могут иметь форму промежуточного ПО ASP.NET Core или фильтров действий. Эти функции могут включать в логирование, авторизацию, добавление заголовков ответов или что-то еще. Обратите особое внимание на эти фрагменты кода, потому что они выполняются для каждого запроса.
Например, промежуточное ПО, которое проверяет при каждом запросе, есть ли у пользователя действующая лицензия. Проверка состоит в отправке запроса на сервер идентификации и запросе к базе данных. Таким образом, каждый запрос должен ждать этих ответов, добавляя кучу времени и увеличивая нагрузку как на сервер идентификации, так и на базу данных. Решением является простой механизм кэширования, который сохраняет информацию о лицензии в памяти на некоторое время.
Если у вас есть аналогичные функции, кеширование может быть хорошим вариантом. Другой вариант - делать что-то партиями. Например, писать в лог каждые 1000 запросов, а не при каждом запросе. Или, возможно, помещать сообщения в очередь, превратив эту функцию в асинхронную.
10. Синхронность против асинхронности
Когда ваш сервер отправляет запрос какому-то сервису и должен дождаться ответа, возникает риск. Что, если этот другой сервис занят обработкой большой очереди запросов? Что, если у него есть проблема с производительностью, от которой вам тоже придётся временно страдать?
Популярный способ решения этой проблемы - изменить синхронный вызов на асинхронный. Обычно это делается с помощью сервиса очереди, такой как Kafka или RabbitMQ. Вместо того, чтобы отправлять запрос и ждать ответа, вы отправляете сообщение в такую очередь. Другой сервис извлекает эти сообщения и обрабатывает их.
А если вам нужен ответ, то сервис отправляет сообщение с ответом в ту же очередь. Вы также будете извлекать сообщения из очереди, и когда придёт ответ, сможете обработать его при необходимости, вне контекста исходного запроса. Если вам нужно отправить ответ клиенту, можно использовать push-уведомление, например, в SignalR.
Преимущество этого подхода в том, что системные компоненты никогда активно не ждут обслуживания. Всё обрабатывается асинхронно. Ещё одно преимущество в том, что сервисы могут быть слабо связаны друг с другом.
Недостаток в том, что это намного сложнее. Вместо простого запроса к сервису вам нужно создать очередь, отправлять и извлекать сообщения, а также работать с такими вещами, как сбой службы, когда сообщение было извлечено, но не обработано.
Источник: https://michaelscodingspot.com/slow-asp-net-server/