Небольшой ориентир с ASP.NET MVC. Код Viewpage:
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 Beta дает следующие результаты:
38 мс, 0,038 мс на канал
120 мс, 0,12 мс на канал
54 мс, 0,054 мс на канал
Запуск того же теста в производственном проекте с примерно 10 контроллерами, которые имеют всего около 100 методов и 30 записей таблицы маршрутизации, производительность сильно ухудшает метод на основе выражений:
31 мс, 0,031 мс на канал
112 мс, 0,112 мс на канал
450 мс, 0,45 мс на канал
Мы довольно часто используем этот метод (ремонтопригодность) и выполняем бенчмаркинг производительности, что значительно ухудшает производительность сайта - страницы быстро содержат около 30 или более таких ссылок, что означает 10 мс дополнительных накладных расходов на одной странице. Даже 0.112ms за URL-адрес составляет около 4 мс чистых затрат на процессор.
Следует отметить, что производительность всех трех вызовов генерации URL-адресов между MVC Preview 3 и Beta (выпущенная вчера) улучшилась в 5 раз.
Переполнение стека, предположительно, поддерживается той же структурой, как вы, ребята, решили эту проблему масштабирования? Либеральное кэширование первой страницы (множество ссылок) и предварительно обработанных элементов управления?
Любые другие производственные сайты в ASP.NET MVC с проблемами производительности или некоторыми хорошими советами?