Работа с базой данных, как правило, является наиболее узким местом в производительности веб-приложений. Но после оптимизации и кэширования запросов можно пойти дальше и посмотреть на другие части кода. Вот три простых совета, которые помогут ASP.NET MVC приложению обработать еще несколько дополнительных запросов.
Возможность использования советов зависит от того, какие особенности ASP.NET MVC 3 используются. Результат не будет большим (в лучшем случае несколько % производительности) и его сложно точно предугадать. Но, возможно, это станет отправной точкой для ваших исследований. Стоит помнить, что любая оптимизация по разному проявляет себя в конкретных сценариях.
1. Отключите неиспользуемые движки представлений
Когда: Веб-приложение использует встроенные шаблоны отображения и редактирования (например, вызывая методы Html.EditorFor() или Html.DisplayFor()). При этом используется только один тип движка представлений.
Почему: ASP.NET MVC умеет очень хорошо кэшировать запросы к файлам (представления, частичные представления, шаблоны и т.д.). Но в одном случае это не срабатывает – это использование встроенных шаблонов для отображения и редактирования (когда все искомые файлы отсутствуют).
Каждый раз, когда происходит обращение к методам Html.EditorFor() или Html.DisplayFor(), каркас ASP.NET MVC 3 создает требуемый HTML код исходя из метаданных модели. Однако, вначале происходит поиск файлов шаблонов, используя все подключенные движки представлений. И чем больше их зарегистрировано в системе, тем дольше будет поиск. А поскольку файлы не будут найдены, то и результат не попадет в кэш. В результате поиск будет повторяться при каждом обращении к таким страницам.
Как: Если используется только один движок представлений, например Razor, то можно удалить все остальные. Самый простой способ – добавить в метод Application_Start() (файл Global.asax) код:
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
2. Избегайте передачи в представления null вместо модели
Когда: Значение null передается в качестве модели в представление, которое использует строго-типизированных HTML помощников (например, Html.TextBoxFor()). Такое часто можно встретить при разработке страниц для ввода данных.
Почему: Строго-типизированные помощники, такие как Html.TextBoxFor(model => model.Name), попытаются использовать модель в переданных им выражениях. Однако, в этом случае результатом будет выброс исключения NullReferenceException. Его поймает каркас, но на странице с большим количеством подобного кода это может сильно ударить по производительности.
Как: Избежать данной ситуации можно просто передав пустой экземпляр модели:
public ActionResult Insert()
{
// return View(); <-- вот этот код передал бы null в качестве модели
return View(new Product());
}
3. Удалите модуль "URL Rewrite" если вы не используете его
Когда: На сервере установлен модуль "URL Rewrite", но ни одно из веб-приложений его не использует.
Почему: При создании ссылки в некоторых случаях каркас ASP.NET MVC п��оверяет не был ли исходный запрос изменен модулем "URL Rewrite". Примером может служить вызов метода Html.ActionLink(). Такой подход необходим для того, чтобы генерируемая ссылка была корректной по отношению к исходному запросу.
Процедура проверки подмены URL может быть достаточно ресурсоёмка и включает опрос переменных сервера. Но перед этим ASP.NET MVC 3 определяет и запоминает текущее состояние модуля "URL Rewrite". Если он выключен или не установлен, то проверка подмены URL не производится.
Что произойдет, если реальной подмены URL не было, но "URL Rewrite" включен? В этом случае ASP.NET MVC 3 все равно выполнит полную проверку исходного запроса. Поэтому указанный модуль стоит отключить, даже если фактически он не используется.
Стоит отметить, что ASP.NET MVC 2 всегда выполняет проверку подмены URL, вне зависимости от того, включен или выключен модуль "URL Rewrite".
Как: Удалите или отключите модуль "URL Rewrite".
По материалам заметки: ASP.NET MVC Performance Tips.