Как улучшить производительность ASP.Net MVC3 при первом обращении к каждой странице?

Question

Если я внесу изменения в просмотр бритвы, перекомпилирую или подожду 15-20 минут, страница может занять от 3 до 20 секунд для рендеринга при первом попадании. Я понимаю, что представление должно быть перекомпилировано после изменения. Я также понимаю, что приложение будет выгружено после определенного периода бездействия, но я подумал, что это будет одноразовый штраф за самый первый удар. Но для меня это, кажется, относится к каждой странице.

Взять, к примеру, мою домашнюю страницу. Согласно YSlow, это «B» с 15 компонентами и весом 250 КБ (включая дополнительный справочник MiniProfiler по jquery). Из MiniProfiler я вижу около 500 мс в первой строке (http://localhost:80). Я предполагаю, что это включает в себя компиляцию представления. Но затем я вижу 1200 мс для Find: Index. Нет вызовов SQL. Общее время загрузки при первом обращении составляет около 3000 мс последующие хиты около 40 мс.

На другой странице с парой частичных представлений родительскому представлению требуется 2400 мс, чтобы "Найти", одному из частичных представлений требуется 1000 мс, чтобы найти. Родительскому представлению также требуется 3200ms для «Render». И наибольшее влияние на первую строку (http://localhost:80/User/Dashboard), который был колоссальные 7000 мс. Эта страница имеет только 3 запроса с общим временем запроса 100 мс. Общее время загрузки было более 15000 мс. Последующие обращения около 250 мс.

Наша настройка - ASP.Net MVC 3, Ninject, EF4.2, механизм просмотра Razor, ELMAH, NLog, Html5Boilerplate и MvcMiniProfiler. Я создал дубликат проекта и удалил Ninject, ELMAH, NLog и MvcMiniProfiler. Производительность была только незначительно быстрее. У нас есть около 15 контроллеров и около 40 представлений, все в одной области.

Это нормальная производительность? Когда мы внедряем в Azure, это даже хуже (естественно), чем локальное тестирование. Есть предложения по улучшению?

Изменить: Первое попадание после компиляции на IIS / localhost (в режиме выпуска и с отладкой отладки = false) может занять около 15 секунд. Развертывание Azure, запущенное в выпуске, имеет более быстрое первое попадание, но все еще в диапазоне 5-10 секунд. Я попробовал проект Дэвида Эббо, но ничего драматического не увидел.

Answer 1

Часто ли вы развертываете это приложение? Если так, то я понимаю, почему производительность первого удара может вызывать беспокойство.

Мы часто развертываем и создали отдельный проект для «разогрева» наших развертываний. Это проект модульного тестирования, который использует WebDriver для проверки каждого некомпилированного представления в нашем приложении после его развертывания.

По сути, вы просто используете API WebDriver для запуска браузера, а затем переходите () к каждому URL, который необходимо скомпилировать. Запустите его один раз, и развертывание будет теплым.

Кроме того, в Azure вы можете отключить тайм-аут простоя, чтобы ваше приложение никогда не простаивало. Мы используем этот скрипт:

%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00

... и запустите его во время развертывания Azure следующим образом:

  <Task commandLine="startup\disableTimeout.cmd" executionContext="elevated" taskType="simple" />