#c# #asp.net-mvc
#c# #asp.net-mvc
Вопрос:
Для рендеринга моего представления требуется много времени. Он состоит из таблицы, заполненной примерно из 90 записей таблицы. Вызовы БД выполняются очень быстро, но для отображения всех записей требуется некоторое время. Вот фрагмент кода, вызывающий медлительность:
<table>
@for (int i = 0; i < Model.PositionEdits.Count; i )
{
<tr>
<td>
@Html.DisplayFor(x => x.PositionEdits[i].PositionID)
@Html.HiddenFor(x => x.PositionEdits[i].PositionID)
</td>
<td>
@Html.DisplayFor(x => x.PositionEdits[i].PositionDescr)
@Html.HiddenFor(x => x.PositionEdits[i].Description)
</td>
<td>
@*editable*@
@Html.DropDownList("Position",
new SelectList(Model.Positions),
Model.PositionEdits[i].Position)
@Html.HiddenFor(x => x.OldPositions[i].Position)
@Html.HiddenFor(x => x.PositionEdits[i].Position)
</td>
</tr>
}
</table>
Я понимаю, что разбивка на страницы решила бы мою проблему, но я надеялся показать все ~ 90 записей на одной странице. Есть ли способ улучшить это представление, чтобы уменьшить время загрузки?
Комментарии:
1. Просто сделайте его асинхронным. Страница загрузится первой, а таблица «появится» по завершении (но 90 или более выпадающих списков могут замедлить работу вашего браузера …)
2. @AdrianoRepetti: Это даже отдаленно неверно. Async не возвращает ответ быстрее. Он просто возвращает поток обратно в пул приложений для отправки других запросов, пока действие не будет готово для него снова. Время загрузки страницы одинаковое — синхронизация и асинхронность. На самом деле, поскольку асинхронность увеличивает накладные расходы, она может оказаться немного медленнее.
3. Вы могли бы кэшировать 90 результатов в течение определенного периода времени (при условии, что они не должны быть в режиме реального времени) и обслуживать из кэша?
4. Является ли эта модель объектом EF или, может быть, объектом NHibernate? На что похожи шаблоны для вызовов DisplayFor?
5. @ChadRuppert это объект EF
Ответ №1:
Прежде всего, если вы все еще находитесь в локальной разработке, особенно если вы используете debug в Visual Studio, сейчас абсолютно неподходящее время беспокоиться о таких вещах, как время загрузки страницы. Вы имеете дело с очень легким одноглавым сервером с множеством накладных расходов, вызванных обратной интеграцией с Visual Studio и ее инструментами. Время загрузки страницы не имеет смысла.
Как только у вас есть что-то работоспособное, вы можете развернуть его в рабочей серверной среде для тестирования производительности. Если вы не используете полномасштабный IIS на выделенном веб-сервере с фактической оперативной памятью и другими ресурсами, которые вы планируете выделить для рабочего сайта, любое измерение производительности бессмысленно, поскольку оно вырвано из контекста.
Если он все еще медленный, чего я не вижу, каким образом это может быть (90 записей на реальном веб-сервере с полным IIS даже со скромным количеством системных ресурсов — это тривиально), вам нужно будет выяснить, какая часть действительно замедляет вас. Существует время, затрачиваемое на первоначальную передачу запроса, запросы к базе данных, фактическое время, затрачиваемое сервером на генерацию ответа, время на отправку этого ответа обратно пользователю, время, необходимое браузеру для рендеринга HTML и CSS, выдачи запросов / получения ответов для дополнительных ресурсов, таких как CSS, файлы JS иизображения и время для выполнения любого JS на странице.
Используя инструменты разработчика вашего браузера (Chrome имеет особенно хороший набор в этом отношении), вы должны иметь возможность видеть диаграмму Ганта, указывающую, когда был выдан каждый запрос и сколько времени потребовалось для получения ответа. Однако это лишь часть истории. Вам понадобятся дополнительные инструменты, чтобы копать глубже, как только вы найдете некоторые проблемные области для рассмотрения. Я лично использую Glimpse. Это даст вам очень подробную информацию о том, сколько времени заняла практически каждая часть процесса и какие части вашего приложения замедляют работу. Шаги, которые необходимо предпринять для устранения проблемы, во многом будут зависеть от того, что на самом деле вызывает проблему, которая до сих пор остается загадкой.
Комментарии:
1. Я не согласен, особенно если вы используете инструмент ORM, который поддерживает отложенную загрузку. Это было бы идеальное время для проверки такого рода вещей. EF Profiler — отличный инструмент для запуска во время разработки. Проблема, о которой он сообщает, может ЛЕГКО быть проблемой отложенной загрузки, а вовсе не проблемой рендеринга.
2. Профилирование запросов — это совершенно иная ситуация, чем прямое тестирование производительности. Это несколько связано, но профилирующие запросы могут даже не фокусироваться на скорости, а на эффективности. Иногда медленнее лучше, если это не приводит к сбою вашей базы данных при загрузке. В OP здесь в общем обсуждается время загрузки страницы, и это преждевременно на данном этапе жизненного цикла приложения.
3. Однако, хотя это верно, такие вещи, как отложенная загрузка, о которой я говорил, часто могут маскироваться под плохое время загрузки страницы. Это все, что я имел в виду.
4. Спасибо, ребята. Я обязательно рассмотрю ваши предложения и попробую как Glimpse, так и EF Profiler. Как ты говоришь, Крис, вероятно, слишком рано начинать какую-либо оптимизацию, но я хотел бы знать, возникает ли проблема во время рендеринга. Я синхронизировал вызовы DB с помощью класса Stopwatch, и они казались очень быстрыми. Кроме того, я удалил содержимое из таблицы (за исключением некоторых фиктивных данных) и добавил содержимое по одному значению за раз. При этом казалось, что выпадающий список дал наибольший эффект с точки зрения времени загрузки. Тем не менее, я все еще не уверен, почему существует такой большой успех.
5. Кроме того, страница, похоже, загружается быстро (все видно), но страница не отвечает.