RenderAction vs RenderPartial производительность

Question

По словам Брэда Уилсона, RenderAction работает медленнее, чем RenderPartial.

Однако есть ли у кого-нибудь статистика, показывающая разницу в производительности?

Я нахожусь в процессе разработки приложения, в котором страницы состоят из "виджетов".

У меня есть два варианта:

Композиция на уровне просмотра

Вызовите RenderAction для каждого виджета. Это самый простой подход, но он означает, что мы выполняем полный цикл MVC для каждого виджета.

Композиция на уровне контроллера

Создайте одну ViewModel для страницы, которая содержит данные, которые нам нужны для каждого виджета. Вызовите RenderPartial для каждого виджета. Это намного сложнее в реализации, но это означает, что мы сделаем только один цикл MVC.

Я протестировал вышеуказанные подходы с 3 различными виджетами на странице, и разница во времени рендеринга составляла десятые доли секунды (вряд ли стоит беспокоиться).

Однако есть ли у кого-нибудь результаты теста более конкретные, чем этот, или, может быть, опыт, пробующий оба подхода?

Answer 1

Недавно я работал над приложением, которое испытывало проблемы с производительностью, и нашел представление, которое выполняло четыре вызова RenderAction, плюс еще одно в макете. Я обнаружил, что каждый вызов RenderAction - даже когда я добавил фиктивное действие, которое возвращало пустое представление - занимал около 200-300 мс (на моей локальной машине). Умножьте на количество звонков, и вы получите огромный успех на странице. В моем случае было четыре вызова, вызывающих около секунды ненужных затрат на стороне сервера. Для сравнения, звонки в RenderPartial были в районе 0-10 мс.

Я бы по возможности не использовал RenderAction в пользу RenderPartial. Контролер должен нести ответственность за возврат всей необходимой информации. В случае виджетов, если вам нужно несколько действий для нескольких виджетов, я бы попытался объединить их в одно действие, чтобы накладные расходы RenderAction возникали только один раз, хотя, если ваш сайт работает адекватно, я бы оставил их отдельно для более чистого дизайна.

Изменить: я собрал эту информацию с помощью MiniProfiler и попадания на сайт. Это не супер точно, но это ясно показывает различия.

Редактировать: Как указал Оскар ниже, у рассматриваемого приложения, вероятно, был какой-то интенсивный код, который выполняется для каждого запроса в global.asax. Величина этого попадания будет зависеть от кода приложения, но RenderPartial полностью исключит выполнение другого цикла MVC.

Answer 2

Я бы предложил еще 2 варианта, оба требуют составления модели представления на уровне контроллера, и оба могут работать вместе (в зависимости от данных)

1. Html.DisplayFor () - отображать шаблоны
2. Помощники через методы расширения

Вариант 2 работает очень хорошо, если вы хотите сохранить эти виджеты в разных сборках, ведь они просто функции, возвращающие строку. Я думаю, что он также имеет лучшую производительность, но, конечно, вы теряете "дружественные дизайнеру" шаблоны. Я думаю, что важно учитывать аспект обслуживания, а не только сырую производительность (до тех пор, пока она вам действительно не понадобится, и даже тогда кеширование будет более полезным).

Для небольших вещей (форматирование даты или имени и т. Д.) Я бы использовал помощников, поскольку html обычно представляет собой диапазон с классом, для более сложных вещей я бы использовал шаблоны отображения.