ASP.NET パフォーマンスの向上 - まずできることは?

0 ユーザーが評価
この投稿には確認済みの回答があります。 0 返信 | 1 サポーター

トップ 10 投稿者 
女性
投稿 18
IG Employee
[IG] Yoshimi 投稿済み: 2010/12/20 17:20
 

ASP.NET パフォーマンスの向上 - まずできることは?

 

元記事 (英語): http://forums.infragistics.com/aspnet/articles/asp-net-performance-a-place-to-start.aspx         

概要

「このページを速くするにはどうしたらいいのですか?」という質問を非常に多く聞かれます。まず、ASP.NET パフォーマンスをサイズとスピードというカテゴリーに分けて考えてみましょう。もちろん、サイズはスピードに直接関係しますが、実はページ ロードの合計が HTML のサイズよりもパフォーマンスに影響があるのです。そこで、サーバー側のパフォーマンスとクライアント側 HTML に分けてご説明します。

サーバー側のパフォーマンス

AJAX によるパフォーマンスの向上は多大ですが、それでも尚多くの ASP.NET アプリケーションで大量のポストバックがみられます。AJAX モデルのポストバックは、すべてのページを更新することなく、静的に行われます。とはいうものの、ポストバックは確かに行われているのです。page_load をサーバーで実行するのに時間がかかる場合、AJAX コールバックも同様に時間がかかります。さて、解決策はあるのでしょうか?アプリケーションのポストバック (AJAX コールバックを含む) の数を制限する方法があります。更に、ポストバックが必要ない時は、サーバー側のコードをすばやく、そして効率的に実行することが必要になります。

以下はその方法です。

キャッシュ:キャッシュはパフォーマンスを飛躍的に向上させます。ページのキャッシュを設定している場合やアプリケーション キャッシュにデータがある場合も、アクセス時間を短縮し、パフォーマンスを向上することができます。                                                                             注:セッション ステートを使用してキャッシュしている場合、サーバーのメモリ使用量が増大します。

データ アクセス: グリッドのページングの結果はご存じだと思いますが、実際にはほんの一部のみがバックエンドデータベースを介したページングの結果です。データをページへ分割してブラウザーへ送信することにより、 HTML サイズは削減し、ページの読み込み時間をカットできます。ウェブ サーバーとデータベース サーバーでも同じことが言えます。
LINQDataSource および ObjectDataSource は ASP.NET のページング可能なデータソースです。つまり、LINQDataSource に 2 ページ目の結果を返すよう要求した場合、データベースへアクセスし、2 ページ目のデータのみを引き出します。 これにより、データベースのサイズにもよりますが、サーバー側の処理が飛躍的に速くなります。 さて、ここでデータベースについて少々ご説明します。 DB でプロファイラーを実行したい場合、SQL インデックスを作成すると結果をより速く取得できます。インデックスは 500K を超える場合に大変重要な要素に成りえます。セッション タイムとサブセカンド レスポンスの間の違いです。

クライアント側のパフォーマンス

私がよく行っているのは、ASP.NET Web アプリケーションで生成された HTML マークアップをチェックして、パフォーマンスを向上する方法を考えることです。 HTML をチェックして何が起こっているのかを理解するための手掛かりを探して、何をしたらパフォーマンスを向上できるのかを考えるのは、まさに宝探しのようなものなのです。               

以下はその詳細です。

キャッシュ: 画像やスクリプト ファイルをキャッシングしていますか?これはほとんどの場合「はい」だと思います。なぜなら IIS のデフォルト設定だからです。Fiddler や FireBug などのユーティリティを実行するとページロード時に読み込まれたすべての項目のキャッシュ ポリシーが表示されます。webresource.axd ファイルがキャッシュされていないのは、ほとんどの場合 web.config ファイルで “Debug=True” 属性にポイントされているからです。このファイルがキャッシュされているかどうかは、HTTP リクエストの結果コード 304 が以下の結果になることを確認してください。結果コード 200 で「キャッシング」が以下のように「プライベート」として表示された場合、アプリケーションの Web.Config の設定がデバッグ モードで実行されている可能性が高いと思われます。この動作により、アプリケーションをデバッグしている場合に古い javascript ファイルの状態を確認できません。ただし、この設定によりサイト パフォーマンスが低下します。

JS リソースを各ページでダウンロードする場合、Debug=True がログとインストルメンテーションを有効にするため、とサーバー側のコードの実行を遅くします。ASP.NET WebDevServer (ファイル システム プロジェクト) ではこのキャッシュの場合には当てはまらないことに注意してください。ウェブ サーバーのキャッシュは、IIS と同様には動作しません。デバッグモードでウェブサイトを配備しないように、以下のようにウェブ サーバーの machine.config に retail=true を追加します。

  1. <configuration>    
  2.    <system.web>  
  3.       <deployment retail="true"/>  
  4.    </system.web>  
  5. </configuration>  

項目 1: retail=true 属性は実稼働サイトをデバッグモードで実行することを防止します

 

image

図 1: FiFiddler の非レスポンスの結果

image

図 2: Fiddler の非レスポンスの結果

ReallyLongIdStringsBecauseWebFormsIsUserFriendly: ASP.NET WebForms は ID プロパティを介してコントロールへアクセスできます。 ID は、各コントロールの ID をその Parent または Container に追加して UniqueID プロパティを固有にすることができます。特に子コントロールの ID を直接制御できない UserControls を使用している場合に大変便利な機能です。ただし、ID が非常に長くなるといった欠点があります。

通常、WebForms アプリケーションは、ContentTemplates を使用した MasterPage で開始します。すべてのコンテンツ コントロールでコントロール階層の 1 レベル深いところから開始していますが、ほとんどのコンテンツ コントロールは、UserControls を格納するパネルに配置されます。もうお分かりですね。コントロールの UniqueID は、他の 4 つのコントロール ID で構成されます。そこで描画される HTML サイズを減らすにはどうしたらよいのでしょうか?答えはコントロールの ID の長さを短くすることです。ID は分かりにくくなりますが、パフォーマンスは向上します。あるいは、Page_Load イベントでコントロールの ID を変更できます (ページ ライフサイクルでコントロール パスウェイの ID を変更することにより、コントロールに影響を及ぼすことがあるため、必ずテストしてください)。ASP.NET 4.0 ではClientIdMode プロパティを追加することによりこの問題が修正されます。

Viewstate: ViewState は接着剤のようなもので、それぞれのポストバックを 1 つのアプリケーションにします。ViewState はデータベースへアクセスする回数を減らすことができ、TextBox ValueChanged の理由です。Viewstate は、非表示の入力フィールドとしてクライアントとサーバーの間を移動するため、ポストバックが倍になります。データは Post 形式でサーバーに送信する必要があります (AJAX コールバックを含む)。

次にデータは、HTML レスポンス コンテンツとしてクライアント ブラウザーへ送り返します。ほとんどの場合、インターネット接続のアップロード スピードはダウンロードに比べて格段に遅くなることに注意してください。フォーム ポストはアップロードです。すなわち、Viewstate データのサーバー ポストはクライアント サーバーへダウンロードするより時間がかかります。Viewstate の使用はほどほどにするのが賢明といえるのではないでしょうか。私の経験では、Viewstate はほとんどの場合必要ありません。必要がなければ無効にすることをお勧めします。

ただし、Viewstate を使用する必要がある場合は、page_load で if(!IsPostback) を確認してください。Viewstate が無効な場合、page_load への変更は次のポストへ保存されません。値を取得しエンコードしてクライアントへ送信、そしてサーバーへのポストバックが、コントロールにプロパティを設定するためだけに行われます。これは Viewstate が必要ないことを説明する良い例だと思います。また、Viewstate は簡単に無効にすることができます。 

圧縮: HTML コンテンツのサイズを減らすことによりページ ロードを速くできます。HTTP レスポンスをすばやく縮小するには、ウェブサーバーの圧縮を有効にすることです。
HTTP 圧縮 (gzip 圧縮) は、サーバー レスポンスを圧縮し、クライアントサーバーへ到達したときに展開されます。ほとんどのブラウザー(IE 4 以上、Firefox、Netscape 6.02 以上、Opera 5.12 で HTTP 圧縮がサポートされています (http://www.http-compression.com/ (英語)) 。 圧縮は JavaScript ファイルでも使用できます。

インライン CSS, JavaScript:  キャッシュの利点と重要性はすでにご説明しましたが、ASPX ページに追加したインライン CSS と JavaScript の特徴は、キャッシュできてもキャッシュしないことです。簡単に修正するには、CSS と JavaScript コードを外部ファイルへ移動することです。 

Web アプリケーションのパフォーマンスを向上させるのは難しいことではありません。プロファイラーを使用する前にできることがいくつかあります。この記事では、パフォーマンスの向上が必要な時にまず試していただきたいことを説明しました。ここで覚えておいていただきたいのは、ここでご紹介した方法は必ずしもすべての状況で適切であるとは限らないということです。たとえば、Viewstate をオフにするためにコードの修正に 2 週間掛かる場合、ページを 1 kb、800 kb のサイズを減らすことができますが、2 週間の作業には見あわなかもしれません。

通常、私は 1 ページにつき <500kb にするようにしています。この記事でご紹介したすべてを試してもパフォーマンスが向上しない場合は、サイズを確認してみてください。UI をもう一度見直して、時には 1 ページを 2 ページにしてみるのもいいかもしれません。ツリー、ドロップダウン リスト、グリッドなどのリッチなデータには、ロードオンデマンド機能を有効にするのもいいでしょう。繰り返しになりますが、まず最初に View Source を使用しない場合のパフォーマンスの違いを確認することをお勧めします! 

ページ 1 / 1 (1 項目) | RSS
Infragistics Japan
インフラジスティックス ジャパン