RenderAction vs RenderPartial performance

Question

Согласно Брэду Уилсону, RenderAction является медленнее, чем RenderPartial.

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

Я занимаюсь разработкой приложения, в котором страницы составлены из «Виджеты».

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

Состав на уровне Просмотр

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

Состав на уровне контроллера

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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