7

Brad Wilsonによると、RenderActionはRenderPartialよりも低速です。

しかし、パフォーマンスの違いを示す統計を誰かが持っていますか？

現在、ページが「ウィジェット」で構成されているアプリケーションを開発中です。

私には2つの選択肢があります：

ビューレベルでの構成

ウィジェットごとにRenderActionを呼び出します。これははるかに簡単なアプローチですが、ウィジェットごとに完全なMVCサイクルを実行していることを意味します。

コントローラーレベルでの構成

各ウィジェットに必要なデータを含むページに対して1つのViewModelを作成します。ウィジェットごとにRenderPartialを呼び出します。これは実装がはるかに複雑ですが、MVCサイクルを1つだけ作成することを意味します。

ページ上の3つの異なるウィジェットを使用して上記のアプローチをテストしましたが、レンダリング時間の違いは10分の1秒でした（心配する価値はほとんどありません）。

しかし、誰かがこれよりも具体的なテスト結果を得たことがありますか、またはおそらく両方のアプローチを試した経験がありますか？

4

2 に答える 2

5

私は最近、パフォーマンスの問題が発生しているアプリケーションに取り組んでおり、RenderAction に対して 4 つの呼び出しを行っているビューと、レイアウト内の別の呼び出しを見つけました。空のビューを返すダミー アクションを追加した場合でも、RenderAction の各呼び出しに約 200 ～ 300 ミリ秒かかることがわかりました (ローカル マシン上で)。呼び出しの数を掛けると、ページのパフォーマンスが大幅に低下します。私の場合、約 1 秒の不要なサーバー側のオーバーヘッドを引き起こす 4 つの呼び出しがありました。比較すると、RenderPartial の呼び出しは 0 ～ 10 ミリ秒の範囲でした。

RenderPartial を優先して、可能な限り RenderAction の使用を避けます。コントローラは、必要なすべての情報を返す必要があります。ウィジェットの場合、複数のウィジェットに対して複数のアクションが必要な場合は、それらを 1 つのアクションにまとめて、RenderAction のオーバーヘッドが 1 回だけ発生するようにします。

編集: MiniProfiler を使用してこの情報を収集し、サイトにアクセスしました。それは超正確ではありませんが、違いを明確に示しています。

編集: Oskar が以下で指摘したように、問題のアプリケーションには、global.asax の各要求に対して実行される集中的なコードが含まれている可能性があります。このヒットの大きさはアプリケーション コードによって異なりますが、RenderPartial は別の MVC サイクルの実行を完全に回避します。

于 2012-08-16T15:00:49.997 に答える
4

さらに2つのオプションをお勧めします。どちらもコントローラーレベルでビューモデルを構成する必要があり、両方が連携できます(データによって異なります)

  1. Html.DisplayFor() - 表示テンプレート
  2. 拡張メソッドによるヘルパー

オプション 2 は、これらのウィジェットを別のアセンブリに保持したい場合に非常にうまく機能します。結局のところ、ウィジェットは文字列を返す関数にすぎません。パフォーマンスも最高だと思いますが、もちろん「デザイナーに優しい」テンプレートは失われます。生のパフォーマンスだけでなく、保守性の側面を考慮することが重要だと思います (本当に必要になるまで、そしてその場合でも、キャッシングがより役立ちます)。

小さなもの (日付や名前の書式設定など) にはヘルパーを使用します。通常、html はクラスを含むスパンであるため、より複雑なものには表示テンプレートを使用します。

于 2012-06-27T15:01:42.930 に答える