この記事では、ASP.NET Web アプリケーションのパフォーマンスを向上させるためのいくつかの方法とテクニックを紹介します。パフォーマンスの問題を解決するのは退屈な仕事であることは誰もが知っていますが、パフォーマンスの問題が発生すると、誰もがコードを書いた開発者を責めます。
以下は翻訳です
パフォーマンスの問題を解決するにはどうすればよいですか? .NET開発者がアプリケーションシステムをリリースする前に確認しておくべき点は以下のとおりです。
1.debug="false"
ASP.NET Webアプリケーションを作成する場合、デフォルト設定は「true」です。開発中は「true」に設定すると非常に便利ですが、アプリケーションをリリースしてデプロイするときは「false」に設定する必要があります。
<compilation defaultLanguage="C#" debug="false" targetFramework="4.0" />
2. トレースをオフにする
トレースはとても怖いものですが、オフにし忘れたことはありませんか?動作しない場合は、必ず web.config を編集して閉じてください。プログラムのリソースを大量に消費します。
<trace enabled="false" requestLimit=”10” pageoutput=”false” traceMode=”SortByTime” localOnly=”true”>
3. セッションを無効にする
セッション追跡を使用しない場合は、必ず無効にしてください。各 asp.net ページで以下を設定できます:
<%@ page language="c#" codebehind="webform1.aspx.cs" autoeventwireup="false" inherits="webapplication1.webform1" enablesessionstate="false" %>
4. リリース バージョンを使用してアプリケーションをデプロイします
アプリケーションを運用環境にデプロイするときは、デバッグ モードではなく必ずリリース バージョン モードを使用してください。デバッグ テンプレートを使用すると、リクエスト タイムアウトが非常に簡単に発生します。リリース バージョンにデプロイすると、大幅な速度の向上に気づくでしょう。
5. ページのビューステートを閉じます
ビューステートは主に送信後のエコーに使用され、ページ内のデータがこのページに送信される場合にのみ役立ちます。デフォルトは「true」です。フォーム データ ポストバックを使用しない場合は、ビュー ステートをオフにすることができます。
<%@ Page EnableViewState="false" %>
6. Response.Redirect の使用は避ける
リダイレクトは、現在の物理サーバーから他のサーバーにジャンプするためにのみ使用されます。このサーバーの開発内でページをリダイレクトするだけの場合は、Server.Transfer 構文を使用してください。これにより、多くの不必要なクライアント リダイレクトが削減されます。
7. StringBuilder クラスを使用し、ToString() メソッドを使用します
String クラスのオブジェクトは不変です。String オブジェクトの再割り当ては、基本的に String オブジェクトを再作成し、そのメソッド ToString に新しい値を割り当てることです。改善はあまり顕著ではありません。文字列を操作する場合は、.NET 名前空間が System.Text である StringBuilder クラスを使用するのが最善です。このクラスは新しいオブジェクトを作成しませんが、Append、Remove、Insert などのメソッドを通じて文字列を直接操作し、ToString メソッドを通じて操作結果を返します。 その定義と動作文は以下の通りです
int num; System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串 str.Append(num.ToString()); //添加数值num Response.Write(str.ToString); //显示操作结果
8. 例外をスローしないようにします
例外が発生すると速度が低下したり、アプリケーションページが異常に表示され、他の操作が実行できなくなります。 try / catch を使用して例外をログ ファイルに記録できます。
9. リソースをリサイクルするには、finally メソッドを使用します
アプリケーション開発中に他のデータベース接続を大量に使用し、ファイルにアクセスする場合は、使用後必ずそれらを閉じてください。 finally ブロックはプログラム内で最後に実行されるブロックであるため、その内部のコードはこの開発メソッド ブロックで実行されることが保証されます。
10. クライアント側のスクリプト検証を使用する
サーバー開発側の検証をクライアント側の検証に置き換えます。サーバー開発側のデータ検証では、サーバー開発リソースが大量に消費され、大量のページ データを返す必要があります。
11. Page.IsPostbackを使う
ポストバックコードを実行しすぎないように注意してください。 Page.IsPostBack プロパティを使用して、ページが最初に読み込まれるときにページ初期化ロジックのみが実行され、応答がクライアントにポストバックされないようにします。
12. ページングを使用する
ほとんどの Web アプリケーション データは表形式で表示されます。ページネーションはアプリケーション開発の効率を活用します。ページの表示速度が向上するため、一度にデータの一部を表示するようにしてください。
13. Ajaxを使用して非同期呼び出しを行う
Ajaxメソッドを使用して非同期呼び出しを行います。
14. 使用されていない HttpModules を削除します
httpModules については、次のように理解できます: 任意の Web アプリケーションに挿入できるユニバーサル HttpApplication イベント フックを確立する。 HttpModule の使用は再利用可能であり、アプリケーション固有のコードは必要なく、web.config にエントリを追加するだけです。 web.config ファイルで、未使用の HttpModules を削除します。
15. 再帰関数/入れ子ループを避ける
パフォーマンスを向上させるには、どのプログラミング言語でも、入れ子ループと再帰関数を避ける必要があります。
16. 不必要なサーバー コントロールを使用しないでください
ASP.NET では、多数のサーバー サイド コントロールによりプログラム開発が容易になりますが、ユーザーがサーバー サイド コントロールを操作するたびに、パフォーマンスの低下を引き起こす可能性もあります。サーバー側のラウンドトリッププロセスとの接続。したがって、Server Control は必要以上に使用しないでください。
17. 複数のオペレーションを呼び出すときは、マルチスレッドを使用してください
問題が発生すると、この問題で単一のスレッドが長時間実行されなくなります。したがって、複数のスレッドを使用してアプリケーションの応答性を向上させることができます。
18. データベース接続とクローズ
データベースリソースにアクセスするには、接続の作成、接続のオープン、接続のクローズといういくつかの操作が必要です。これらのプロセスでは、認証に合格するためにデータベースとの複数回の情報交換が必要となり、サーバー リソースが消費されます。 ASP.NET は、データベースの開閉によるパフォーマンスへの影響を改善するための接続プール (接続プール) を提供します。システムはユーザーのデータベース接続を接続プールに置き、必要に応じて接続を取り出し、接続が閉じられたときに接続を再利用して、次の接続要求を待ちます。接続プールのサイズは制限されており、接続プールが最大制限に達した後も接続を作成する必要がある場合、パフォーマンスに大きな影響を与えます。したがって、データベース接続を確立した後は、本当に操作が必要な場合にのみ接続を開き、使用後はすぐに閉じることで、データベース接続が開いている時間を最小限に抑え、接続制限を超えないようにすることができます。
19. 早送り専用のデータ カーソルには SqlDataReader クラスを使用します
SqlDataReader クラスは、SQL Server データベースから取得したフィード専用のデータ ストリームを読み取る方法を提供します。 ASP.NET アプリケーションの作成時に SqlDataReader クラスを使用できる状況が発生した場合、SqlDataReader クラスは DataSet クラスよりも高いパフォーマンスを提供します。これは、SqlDataReader が SQL Server のネイティブ ネットワーク データ転送形式を使用してデータベース接続からデータを直接読み取るためです。さらに、SqlDataReader クラスは IEnumerable インターフェイスを実装しており、これによりデータをサーバー コントロールにバインドすることもできます。詳細については、SqlDataReader クラスを参照してください。 ASP.NET がデータにアクセスする方法については、「ASP.NET を使用したデータへのアクセス」を参照してください。
20. 高性能 SQL ステートメントのルール
全テーブル スキャンを避けるようにする
where 節内のフィールドでの null 値判定を避けるようにする
where 節内の != や 演算の使用を避けるようにする記号
条件
を接続するために where 句内で or を使用することは避けてください
。また、注意して使用してください
条件内の "=" の左側で関数、算術演算、その他の式操作を実行しないでください。 where 句
Update ステートメントでは、1 つまたは 2 つのフィールドのみを変更する場合は、すべてのフィールドを更新しません
大量のデータ (ここでは数百が大きいとみなされます) を含む複数のテーブルの JOIN の場合、最初にページネーションしてから JOIN する必要があります, そうしないと、論理読み取りが非常に高くなり、パフォーマンスが非常に悪くなります
できるだけchar/ncharの代わりにvarchar/nvarcharを使用してください
21. キャッシュ
平たく言えば、キャッシュはスペースを時間と交換するテクノロジーです。これは、取得したデータを一定期間メモリに保存することを意味し、サーバーはデータベースや実際のデータ ソースを読み取るのではなく、メモリに保存されたデータを読み取ります。 キャッシュは、Web サイトのパフォーマンスを最適化するために不可欠なデータ処理メカニズムであり、データベースの負荷を効果的に軽減します。 ASP.NETにおけるキャッシュは主に、
ページキャッシュ
データソースキャッシュ
カスタムデータキャッシュ
22. 負荷分散とサーバー追加
負荷分散は、性の手段であるスケーラビリティを実現することだけを考えるべきではありません。確かにスケーラビリティは向上しますが、リクエストとユーザーが複数のサーバーに分散されるため、多くの場合、Web アプリケーションのパフォーマンスが向上します。
23. FxCop によるコード検査と最適化
FxCop は、ルールベースのエンジンを使用してコードの非標準部分をチェックするコード分析ツールです。独自のルールをカスタマイズしてこのエンジンに追加することもできます。ルールの一部は次のとおりです。 NeutralResourcesLanguageAttribute
メンバーを静的としてマークするなど。
24.ASP.NETパフォーマンス監視ツール
コードのパフォーマンスを監視するために使用されるツールです。
.NET Memory Analyzer
Red Gate ANTS Performance Analysis Tool
Fiddler
Performance Counter
結論:上記はパフォーマンスチューニングのヒントです。パフォーマンスのチューニングは 1 日や 2 日の作業ではなく、反復的なプロセスです。 Web サイト開発者にとって、ASP.NET アプリケーションを作成するときにパフォーマンスの問題に注意し、良い習慣を身につけ、アプリケーションのパフォーマンスを向上させることで、少なくとも必要なハードウェアのアップグレードを延期し、Web サイトのコストを削減できます。