Небольшой бенчмарк с ASP.NET MVC. Код страницы просмотра:
public string Bechmark(Func<string> url)
{
var s = new Stopwatch();
var n = 1000;
s.Reset();
s.Start();
for (int i = 0; i < n; i++)
{
var u = url();
}
s.Stop();
return s.ElapsedMilliseconds + " ms, " + ((s.ElapsedMilliseconds) / (float)n) + " ms per link<br/>";
}
Посмотреть код:
<%= Bechmark(() => Url.Action("Login", "Account")) %>
<%= Bechmark(() => Url.Action("Login", "Account", new {username="bla", password="bla2", returnurl="blabla32", rememberme=false} )) %>
<%= Bechmark(() => Html.BuildUrlFromExpression<AccountController>(a=>a.ChangePassword("bla", "bla", "ya")) ) %>
Выполнение этого на типичном блокноте Core2 в шаблоне нового проекта по умолчанию с бета-версией ASP.NET MVC дает следующие результаты:
38 мс, 0,038 мс на канал
120 мс, 0,12 мс на канал
54 мс, 0,054 мс на ссылку
Запустив тот же тест в производственном проекте с примерно 10 контроллерами, которые имеют всего около 100 методов и 30 записей в таблице маршрутизации, производительность метода на основе выражений значительно снижается:
31 мс, 0,031 мс на канал
112 мс, 0,112 мс на канал
450 мс, 0,45 мс на канал
Мы довольно часто используем этот метод (ремонтопригодность) и проводим некоторые тесты производительности, это сильно снижает производительность сайта - страницы быстро содержат около 30 или более таких ссылок, что означает 10 мс дополнительных накладных расходов на одну страницу. Даже 0,112 мс на URL — это около 4 мс чистой нагрузки ЦП.
Следует отметить, что производительность всех трех вызовов генерации URL между MVC Preview 3 и Beta (выпущенной вчера) улучшилась в 5 раз.
Предполагается, что Stack Overflow работает на той же платформе, как вы, ребята, решили эту проблему масштабирования? Либеральное кеширование главной страницы (много ссылок) и предварительно обработанные элементы управления?
Любые другие производственные веб-сайты в ASP.NET MVC с проблемами производительности или какие-либо полезные советы?
