Как улучшить производительность приложений ASP.NET MVC?

Question

Как улучшить производительность приложения ASP.NET MVC?

Answer 1

Просто хотел добавить мои 2 цента. Самый эффективный способ оптимизировать генерацию URL-маршрута в приложении MVC - это ... не генерировать их вообще.

Большинство из нас, так или иначе, более или менее знают, как URL генерируются в наших приложениях, поэтому просто используя статический Url.Content("~/Blahblah") вместо Url.Action() или Url.RouteUrl(), где это возможно, бьет все остальные методы почти в 20 раз и даже больше.

PS. Я провел тест из нескольких тысяч итераций и опубликовал результаты в своем блоге , если заинтересован.

Answer 2

1. Реализация Gzip.
2. Использовать асинхронный рендеринг для частичных представлений.
3. Минимизировать попадания в базу данных.
4. Использовать скомпилированный запрос.
5. Запустите профилировщик и найдите ненужные хиты. Оптимизируйте все хранимые процедуры, которые возвращают ответ более чем за 1 секунду.
6. Использовать кеширование.
7. Использование минимизация комплектации оптимизация.
8. Используйте утилиты HTML 5, такие как кеш сеанса и локальное хранилище, для содержимого, доступного только для чтения.

Answer 3

1: получить время. Пока вы не знаете, где замедление, вопрос слишком широк, чтобы ответить. Проект, над которым я работаю, имеет именно эту проблему; Там нет регистрации, чтобы даже знать, как долго определенные вещи; мы можем только догадываться о медленных частях приложения, пока не добавим время в проект.

2: Если у вас есть последовательные операции, не бойтесь слегка многопоточности. ОСОБЕННО, если задействованы блокирующие операции. PLINQ твой друг здесь.

3: Создайте свои представления MVC при публикации ... Это поможет с некоторыми "попаданиями на первую страницу"

4: Некоторые утверждают, что хранимая процедура / преимущества ADO скорости. Другие приводят доводы в пользу скорости развития EF и более четкого разделения ярусов и их назначения. Я видел очень медленные разработки, когда SQL и обходные пути использования Sprocs / Views для извлечения и хранения данных. Кроме того, ваша сложность тестирования возрастает. Наша текущая кодовая база, которую мы конвертируем из ADO в EF, работает не хуже (а в некоторых случаях лучше), чем старая модель Hand-Rolled.

5: Тем не менее, подумайте о прогреве приложения. Часть того, что мы делаем, чтобы помочь устранить большинство наших проблем производительности EF, заключалась в добавлении специального метода прогрева. Он не прекомпилирует какие-либо запросы или что-либо еще, но помогает в большей части загрузки / генерации метаданных. Это может быть еще более важно при работе с моделями Code First.

6: Как уже говорили другие, не используйте состояние сеанса или ViewState, если это возможно. Они не обязательно являются оптимизацией производительности, о которой думают разработчики, но как только вы начнете писать более сложные веб-приложения, вы захотите быстро реагировать. Состояние сеанса исключает это. Представьте себе длинный запрос. Вы решаете открыть новое окно и попробовать менее сложное. Что ж, возможно, вы также ждали с включенным состоянием сеанса, потому что сервер будет ждать до завершения первого запроса, прежде чем перейти к следующему для этого сеанса.

7: свести к минимуму поездки в базу данных. Сохраняйте материалы, которые вы часто используете, но реально не измените их в свой .Net Cache. Попытайтесь пакетировать ваши вставки / обновления, где это возможно.

7.1. Избегайте кода доступа к данным в представлениях Razor без чертовски веских причин. Я бы не сказал этого, если бы не видел это. Они уже обращались к своим данным, когда собирали модель, почему, черт возьми, они не включили ее в модель?

Answer 4

В своем стремлении оптимизировать клиентскую часть не забывайте о уровне базы данных. У нас было приложение, которое ушло от 5 секунд для загрузки до 50 секунд за ночь.

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

Answer 5

Если вы запускаете приложение ASP.NET MVC в Microsoft Azure (IaaS или PaaS), выполните следующие действия, по крайней мере, до первого развертывания.

• Сканирование вашего кода с помощью статического анализатора кода на наличие любых типов долгов кода, дублирования, сложности и безопасности.
• Всегда включайте Application Insight и часто отслеживайте производительность, браузеры и аналитику, чтобы найти проблемы приложения в реальном времени.
• Реализация Azure Redis Cache для статических и менее частых изменений данных, таких как изображения, ресурсы, общие макеты и т. Д.
• Всегда полагайтесь на инструменты APM (Application Performance Management), предоставляемые Azure.
• См. Карту приложения часто, чтобы исследовать производительность связи между внутренними частями приложения.
• Отслеживание производительности базы данных / виртуальной машины.
• При необходимости используйте балансировщик нагрузки (горизонтальная шкала) и в рамках бюджета.
• Если ваше приложение имеет целевую аудиторию по всему миру, используйте Azure Trafic Manager для автоматической обработки входящего запроса и перенаправления его в наиболее доступный экземпляр приложения.
• Попробуйте автоматизировать мониторинг производительности, написав предупреждения, основанные на низкой производительности.

Answer 6

Использование комплектов и минимизации также помогает повысить производительность. Это в основном сокращает время загрузки страницы.

Answer 7

Вот что нужно сделать

1. Режим ядра Cache
2. Режим конвейера
3. Удалить неиспользуемые модули
4. runAllManagedModulesForAllRequests
5. Не пишите в wwwroot
6. Удалить неиспользуемые механизмы просмотра и язык