ASP.NET MVCのパフォーマンス

https://stackoverflow.com/questions/43743

09-06-2019
|

質問

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

これは、ASP.NET WebForms から 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 秒あたりの接続数とリクエストの速度が大幅に向上します。

Webフォームは本質的に遅い、あるいはリソースを大量に消費するものだと考えている人の多くは、その責任を間違ったところに押し付けていると思います。Web フォームアプリの最適化を依頼されると、10 回中 9 回、アプリの作成者がビューステートの目的を誤解している箇所が多すぎます。ビューステートが完璧だとか何かと言っているわけではありませんが、ビューステートを悪用するのは非常に簡単であり、ビューステートフィールドの肥大化を引き起こしているのはこの悪用です。

この記事は、これらの虐待の多くを理解するのに非常に役立ちました。 https://weblogs.asp.net/infinitiesloop/truly- Understanding-viewstate

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

私のテストでは、MVC では 1 秒あたりのリクエスト数が 2 倍から 7 倍増加していることがわかりましたが、それは Web フォームアプリの構築方法によって異なります。「hello world」テキストのみを使用し、サーバー側の制御を行わない場合、mvc は約 30 ～ 50% 高速になります。

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

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

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

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

Rob Connery 自身も、ASP.NET MVC は 1 秒あたり 8000 件のリクエストを処理できるという ScottGu の主張をある程度認めています。

おそらく、ジェフと彼のスタッフは、このサイトの開発から何らかのヒントを与えることができるでしょう。

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

メトリクスは次の場所で入手できます。 http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

すべての比較 mvc はリストの中下位/下位上位に位置し、最適化された Web フォームの使用法は上位中位/上位下位に位置します。

これらの指標に対する逸話的ですが非常に真剣な検証、 www.microsoft.com MVC ではなく Web フォームによって提供されます。ここで、経験的に MVC の方が速かったら MVC を選択しなかったと信じている人はいますか?

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

私は約 1 年前に MVC での作業を開始しましたが、インスピレーションはありましたが、感動はしませんでした。

私はビューステートが大嫌いで、ASP.NET に関してはビューステートが諸悪の根源であると考えています。これが、私がそれを使用しない理由ですが、正直に言うと、なぜ使用するのでしょうか?

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

ここで、私は、ASP.NET MVC アプリケーションは、使用方法に応じて高速になる、とまで言いたいと思います。Web フォームを完全に放棄すると、ASP.NET のライフサイクルとオブジェクトモデルが膨大になるため、処理が速くなります。

書いているときは軍隊をインスタンス化していることになります...待ってください。ビューのレンダリングに参加する多数のオブジェクトが表示されます。これは、ASPX ページ自体で最小限の動作を表現する場合よりも遅くなります。(Visual Studio での ASPX ページのサポートは適切であるため、ビューエンジンの抽象化については気にしていませんが、コードが肥大化したり、私のアプリケーションに接続するもの)。

私は、動的再コンパイル (System.Reflection.Emit) を利用して、必要に応じて特別な目的のオブジェクトとコードを生成する方法を見つけました。このコードの実行はリフレクションよりも高速ですが、最初はリフレクションサービスを通じて構築されます。これにより、MVC フレーバーのフレームワークに優れたパフォーマンスが与えられましたが、同時に非常に静的に型付けされました。文字列と名前と値のペアのコレクションは使用しません。代わりに、カスタムコンパイラサービスは、参照型が渡されるコントローラアクションへのフォームポストを書き換えます。舞台裏では多くの処理が行われていますが、このコードは高速であり、WebForms や MVC フレームワークよりもはるかに高速です。

また、URL を記述するのではなく、後でどのコントローラーアクションを呼び出すかを指示する URL に変換されるラムダ式を記述します。これは特に高速ではありませんが、URL が壊れるよりは優れています。これは、静的に型指定されたオブジェクトだけでなく、静的に型指定されたリソースがある場合と似ています。静的に型付けされた Web アプリケーションですか?それが私が望むものです！

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

Visual Studio で作成されたプロジェクト。1 つは mvc4 テンプレート、もう 1 つは WebForm (従来型) です。そして、WCATで負荷テストを行うと、これが結果です、

MVC4 は WebForms よりもかなり遅いのですが、何かアイデアはありますか?

enter image description here

MVC4

約11rpsを獲得できます
RPS は 2 CPU サーバーでも 4 CPU サーバーでもかなり低い

enter image description here

ウェブフォーム (aspx)

2500rpmを超える可能性があります
パフォーマンスのキラーは MVC Bata または RC のバグであることが判明しました。バンドルのものを削除するとパフォーマンスが向上します。現在、最新バージョンではこの問題が修正されています。

パフォーマンスは何をしているかによって異なります...通常、MVC は、Viewstate が存在しないことと、デフォルトでポストバックよりもコールバックで動作することが主な理由で、asp.net よりも高速です。

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

また、CSS と JavaScript を結合して縮小したり、画像をグループ化してスプライトとして使用したりするなど、Web サイトのパフォーマンスを向上させるのに役立つ、MVC (および Webform) 用のナゲットも多数あります。

Web サイトのパフォーマンスはアーキテクチャに大きく依存します。関心事が適切に分離されたクリーンなコードは、よりクリーンなコードと、パフォーマンスを向上させる方法についてのより良いアイデアをもたらします。

このテンプレートをご覧ください。」Neos-SDI MVC テンプレート" これにより、デフォルトでパフォーマンスが大幅に向上したクリーンなアーキテクチャが作成されます (確認してください) Mvcテンプレート Webサイト）。

enter image description here

いくつかの基本コードを使用して小規模な 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 つの測定値が取得され、すべての測定値が Reading 1、2 などとして公開されます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow