ASP.NET MVCはASP.NET WebFormsよりも30倍高速であるという野生の発言を見つけました。実際のパフォーマンスの違いは何か、これは測定されているか、パフォーマンスの利点は何か。

これは、ASP.NET WebフォームからASP.NET MVCへの移行を検討するのに役立ちます。

結論を出すために必要な種類のスケーラビリティとパフォーマンステストは実行していません。ScottGuは潜在的なパフォーマンス目標について議論していたと思います。ベータ版とRTMに移行するにつれて、社内でより多くのパフォーマンステストを行う予定です。ただし、パフォーマンステストの結果の公開に関するポリシーがどのようになっているかはわかりません。

いずれにせよ、そのようなテストは実際に実際のアプリケーションを考慮する必要があります...

これは、A） WebFormsアプリケーションの実装方法、およびB） MVCアプリケーションの実装方法に大きく依存するため、明確に答えるのは難しい質問だと思います。「生の」フォームでは、MVCはおそらくWebFormsよりも高速ですが、何年にもわたるツールと経験により、高速なWebFormsアプリケーションを構築するための多くの手法が生み出されてきました。ASP.NETの上級開発者が、MVCアプリケーションの速度に匹敵するWebFormsアプリケーションを作成できるか、少なくとも無視できる程度の差を達成できることを私は喜んで望みます。

実際の違いは、@ tvanfossonが示唆したように、テスト容易性とクリーンなSoCにあります。パフォーマンスの向上が主な関心事である場合、WebFormsですぐに出荷してMVCで再構築を開始することは大きな理由ではないと思います。少なくとも、Webフォームを最適化するために利用できる手法を試すまでは。

ビューステートを削除し、送信された出力をプログラムで操作できるようにするだけで、私のページの1つを2MBペイロードから200kに減らしました。

サイズだけでも、処理は同じでしたが、1秒あたりの接続数と要求の速度が大幅に向上します。

WebFormsは本質的に遅いかリソースを大量に消費していると考える人々の多くは、責任を間違った場所に置いていると思います。私がWebフォームアプリを最適化するために呼び出されたとき、10回のうち9回は、アプリの作成者がビューステートの目的を誤解している場所が多すぎます。ビューステートが完璧であるとは言いませんが、乱用するのは簡単すぎる方法です。この乱用がビューステートフィールドの肥大化の原因になっています。

この記事は、私がこれらの虐待の多くを理解するのを助ける上で貴重なものでした。https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

MVCとWebFormsを有効に比較するには、両方のアプリがアーキテクチャを正しく使用していることを確認する必要があります。

私のテストでは、MVCで2倍から7倍のreq / sec以上の要求が示されていますが、Webフォームアプリの構築方法によって異なります。「hello world」というテキストだけがあり、サーバー側の制御がない場合、mvcは約30〜50％速くなります。

私にとって、MVCの本当の「パフォーマンス」向上は、アプリケーションのテスト可能な表面の増加です。WebFormsでは、テストが難しいアプリケーションがたくさんありました。MVCでは、テスト可能になるコードの量は基本的に2倍になります。基本的に、簡単にテストできないのは、レイアウトを生成するコードだけです。ビジネスロジックとデータアクセスロジック（ビューで使用される実際のデータを入力するロジックを含む）はすべてテストできるようになりました。同じようにパフォーマンスが向上すると思いますが、ページのライフサイクルは大幅に簡素化され、Webプログラミングの影響を受けやすくなります。たとえ同じでも、少し遅くても、品質の観点から切り替える価値があります。

ここでの問題は、ASP.Net MVCが古いWebフォームよりどれほど高速であっても、ほとんどの時間がデータベース内にあるため、違いが生じないことです。ほとんどの場合、Webサーバーは0〜10％のCPU使用率でデータベースサーバーを待機しています。Webサイトで非常に多くのヒットがあり、データベースが非常に高速でない限り、大きな違いに気付くことはないでしょう。

初期のASP.NET MVC開発からのものであると私が見つけることができる唯一の具体的な数は、このフォーラムスレッドにあります。

http://forums.asp.net/p/1231621/2224136.aspx

Rob Connery氏自身も、ScottGuがASP.NET MVCは1秒あたり8000のリクエストに対応できると主張しているとの声明をある程度認めています。

たぶんジェフと彼の乗組員は、このサイトの開発から何らかのヒントを与えることができます。

受け入れられた意見に反して、最適化されたWebフォームの使用は、生のパフォーマンスに関してMVCを完全に殺します。Webフォームは、MVCが提供するよりもはるかに長くhtmlを提供するタスクのために高度に最適化されています。

指標はhttp://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=dbで入手できます

すべての比較mvcはリストの下位中位/下位上位ランキングにありますが、最適化されたWebフォームの使用は上位中位/上位下位ランクに配置されます。

これらのメトリクスに対する事例的ではあるが非常に深刻な検証であるwww.microsoft.comは、MVCではなくWebフォームによって提供されます。ここにいる誰かが、経験的に高速であればMVCを選択しなかったと信じていますか？

これに答える方法は本当にありません。MVCはデフォルトでWebフォームビューエンジンを使用し、任意の数のカスタムビューエンジンを使用するように構成できるため、パフォーマンスの比較が必要な場合は、より具体的にする必要があります。

1年ほど前にMVCで仕事を始めましたが、刺激を受けましたが、感銘を受けませんでした。

私はビューステートを嫌い、ASP.NETに関してはすべての悪の根源だと考えています。これが私がそれを使用しない理由であり、完全に正直に言うと、なぜあなたはどうしますか？

私は基本的にASP.NET MVCフレームワークの概念を取り入れ、独自の方法で構築しました。でもいくつか変更しました。コントローラーのラッピングコード、つまり動的再コンパイルを中心としたURLルーティングコードを作成しました。

さて、ASP.NET MVCアプリケーションは、使用方法に基づいてより高速になると言えるでしょう。WebFormsを完全に放棄すると、ASP.NETのライフサイクルとオブジェクトモデルが膨大になるため、より速くなります。

あなたが書いているとき、あなたは軍をインスタンス化しています...待ってはいけません、あなたのビューのレンダリングに参加するオブジェクトの軍団。これは、ASPXページ自体で最小限の動作をどこに表現するかよりも遅くなります。（Visual StudioでのASPXページのサポートはまともなので、ビューエンジンの抽象化は気にしませんが、コードブロートまたは変更できないため、WebFormsをコンセプトとして、基本的にはすべてのASP.NETフレームワークを完全に削除しました。アプリケーションを配線するもの）。

特別な目的のオブジェクトとコードを必要に応じて出力するために、動的再コンパイル（System.Reflection.Emit）に依存する方法を見つけました。このコードの実行はリフレクションよりも高速ですが、最初はリフレクションサービスを介してビルドされます。これにより、MVCフレーバーフレームワークのパフォーマンスが向上しましたが、静的に型付けされています。文字列と名前と値のペアのコレクションは使用しません。代わりに、私のカスタムコンパイラサービスは、参照型が渡されるコントローラーアクションへのフォームポストの書き換えを行います。背後では多くのことが行われていますが、このコードは高速で、WebFormsやMVCフレームワークよりもはるかに高速です。

また、URLは記述せず、後で呼び出すコントローラーアクションを通知するURLに変換されるラムダ式を記述します。これは特に高速ではありませんが、URLが壊れている場合に勝ります。静的に型付けされたリソースと静的に型付けされたオブジェクトがあった場合と同じです。静的に型付けされたWebアプリケーション？それが私が欲しいものです！

より多くの人にこれを試してみることを勧めます。

ビジュアルスタジオで作成されたプロジェクト。1つはmvc4テンプレート、もう1つはWebForm（旧式）です。そして、WCATで負荷テストを行うと、これが結果です、

MVC4はWebFormsよりもかなり遅いです。

MVC4

• 約11 rps
• 2 CPUまたは4 CPUサーバーの両方でrpsが非常に低い

WebForms（aspx）

• 2500 rpsを超える可能性があります

• パフォーマンスキラーは、MVCバタまたはRCのバグであることが判明しています。バンドルを削除すると、パフォーマンスが向上します。現在、最新バージョンはこれを修正しました。

パフォーマンスは何をしているのかに依存します...通常、MVCはasp.netより高速です。これは、ほとんどの場合、Viewstateがなく、デフォルトでMVCがポストバックよりもコールバックで動作するためです。

Webフォームページを最適化すると、MVCと同じパフォーマンスが得られますが、多くの作業が必要になります。

また、それらはMVC（およびWebform）の多くの核心であり、CSSとJavaScriptを組み合わせて縮小したり、画像をグループ化してスプライトとして使用したりするなど、Webサイトのパフォーマンスを向上させるのに役立ちます。

Webサイトのパフォーマンスは、アーキテクチャによって大きく異なります。問題を適切に分離したクリーンなコードを使用すると、コードがよりクリーンになり、パフォーマンスを向上させるためのより良いアイデアが得られます。

このテンプレート「Neos-SDI MVCテンプレート」を見ると、デフォルトで多くのパフォーマンスが向上したクリーンなアーキテクチャが作成されます（MvcTemplate Webサイトを確認してください）。

いくつかの基本コードを使用して小さなVSTS負荷テスト実験を行ったところ、ASP.NET MVCの応答時間がASP.NET Webformsに比べて2倍高速であることがわかりました。上記は、プロット付きの添付グラフです。

この負荷テストの実験については、このCP記事https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compariから詳細を読むことができます。

テストは、VSTSとtelerik負荷テストソフトウェアを使用して、以下の仕様で実施されました。

ユーザーは25人のユーザーをロードします。

テストの実行時間は10分でした。

マシン構成DELL 8 GB Ram、Core i3

プロジェクトはIIS 8でホストされていました。

プロジェクトはMVC 5を使用して作成されました。

ネットワークLAN接続が想定されました。したがって、このテストでは、現在のところネットワークラグは考慮されていません。

テストで選択したChromeおよびInternet Explorerのブラウザー。

未知のイベントを平均化するためにテスト中に取得された複数の読み取り。取られた7つのリーディングとすべてのリーディングは、この記事では1、2などとして公開されています。