ASP.Net アプリケーションのパフォーマンスを向上させる 10 の方法
著者：Eve Cole
更新時間：2009-06-30 15:49:49
この記事では次のことについて説明します。
asp.net アプリケーションのパフォーマンス向上についてよく言われる迷信 asp.net アプリケーションのパフォーマンスを向上させるための役立つヒント
Asp.net アプリケーションでデータベースを操作するための推奨事項
Asp.net でのキャッシュとバックグラウンド処理
現在、ASP.NET Web アプリケーションの作成は非常に簡単になっており、多くのプログラマーは、パフォーマンスの良いアプリケーションの構築に時間を費やすことを望んでいません。この記事では、Web アプリケーションのパフォーマンスを向上させるための 10 の方法について説明します。 ASP.NET アプリケーションは Web アプリケーションのサブセットにすぎないため、説明を ASP.NET アプリケーションだけに限定するつもりはありません。また、この記事では、Web アプリケーションのパフォーマンスを向上させるための完全なガイドを提供することはできません。これを行うには、1 冊の本が必要になるためです。この記事は、Web アプリケーションのパフォーマンスを向上させるための適切な出発点を提供するだけです。 （あとは自分でゆっくり勉強するだけです）。
仕事以外でも、私はよくロッククライミングに行きます。毎回のロッククライミングの前に、ロッククライミングのルートマップを確認し、過去に成功したロッククライマーのアドバイスを読みます。彼らの成功体験が必要だからです。同様に、パフォーマンスの問題があるプログラムを変更したり、高パフォーマンスの Web サイトを開発する必要がある場合は、高パフォーマンスの Web アプリケーションの作成方法も学ぶ必要があります。
私の個人的な経験は主に、Microsoft の asp.net グループでプログラム マネージャーとして働き、 www.asp.net Web サイトを運営および管理し、コミュニティ サーバー (asp.net フォーラムの統合およびアップグレードされたバージョン) の開発を支援したことに由来しています。 、.Text、および nGallery ソフトウェア）。これらの経験が私に役立つと思います。
アプリケーションをさまざまな論理層に分割することを考えるかもしれません。 3 層物理アーキテクチャまたは N 層アーキテクチャについても聞いたことがあるかもしれません。これは、実行のためにさまざまなプログラム機能をさまざまなハードウェアに物理的に割り当てるアーキテクチャ モデルです。このように、アプリケーションのパフォーマンスを向上させたい場合は、ハードウェアを追加することで目標を達成できます。この方法によりアプリケーションのパフォーマンスが向上するのは当然ですが、この方法の使用は避けるべきです。したがって、可能な限り、ASP.NET ページとそれが使用するコンポーネントをアプリケーションに組み込む必要があります。
分散展開と Web サービスまたはリモート処理の使用により、アプリケーションのパフォーマンスが 20% 以上低下します。
データ層は少し異なります。独立してデプロイし、別のハードウェアを使用して実行することをお勧めします。それにもかかわらず、データベースは依然としてアプリケーションのパフォーマンスのボトルネックとなっています。したがって、プログラムを最適化したい場合、最初に思い浮かぶのはデータ層の最適化です。
パフォーマンスの問題を引き起こしているアプリケーションの領域を変更する前に、問題の原因となっているプログラムが厳しいかどうかを確認する必要があります。パフォーマンス プロファイラーは、アプリケーションのどこでどれくらいの時間がかかっているかを調べるのに非常に役立ちます。これらは私たちが直感的に感じることができない場所です。
この記事では、2 種類のパフォーマンスの最適化について説明します。1 つは、asp.net のキャッシュの使用などの大きなパフォーマンスの最適化 (大きな最適化)、もう 1 つは小さなパフォーマンスの最適化 (小さな最適化) です。小さなパフォーマンスの最適化が非常に役立つ場合があります。コードに小さな変更を加えて、それを一度に 1,000 回または 1 万回呼び出します。大幅なパフォーマンスの最適化を行うと、アプリケーションの速度が大幅に向上することがわかります。小規模なパフォーマンスの最適化では、リクエストあたり 1 マイクロ秒しか改善されない可能性がありますが、1 日あたりのリクエスト数が多い場合、アプリケーションのパフォーマンスは大幅に向上します。
データ層のパフォーマンス
アプリケーションのパフォーマンスを最適化したい場合は、次の順序で作業できます。 コードはデータベースにアクセスする必要がありますか?その場合、どのくらいの頻度でデータベースにアクセスする必要がありますか?同様に、このテスト方法は、Web サービスやリモート処理を使用するプログラム コードでも使用できます。この記事では、Web サービスとリモーティングを使用したプログラムの最適化の問題については説明しません。
コード内にデータベースにアクセスする必要があるリクエストがあり、同じ関数を他の場所で実装しているコードがある場合は、最初にそれを最適化する必要があります。非常に大きなパフォーマンスの問題がない限り、変更と改善を行い、テストを続行します。クエリの最適化、データベースへの接続、データ セットのサイズの返し、クエリを返すのにかかる時間に時間を費やした方がよいでしょう。
経験の要約に基づいて、アプリケーションのパフォーマンスの向上に役立つ 10 の経験を見てみましょう。どれだけ効率が向上するかという観点から、大きいものから小さいものまで順番に説明します。
1. 複数のデータセットを返す
データベースのアクセス コードを確認して、複数回返されるリクエストがあるかどうかを確認してください。往復するたびに、アプリケーションが応答できる 1 秒あたりのリクエストの数が減少します。 1 つのデータベース リクエストで複数の結果セットを返すことにより、データベースとの通信にかかる時間が短縮され、システムがスケーラブルになり、リクエストに応答するためのデータベース サーバーの作業負荷が軽減されます。
動的 SQL ステートメントを使用して複数のデータ セットを返す場合は、動的 SQL ステートメントの代わりにストアド プロシージャを使用することをお勧めします。ビジネス ロジックをストアド プロシージャに記述するかどうかについては、少し議論の余地があります。しかし、ビジネス ロジックをストアド プロシージャに記述すると、返される結果セットのサイズが制限され、ネットワーク データ トラフィックが削減され、ロジック層でデータをフィルターする必要がなくなるのは良いことだと思います。
SqlCommand オブジェクトの ExecuteReader メソッドを使用して、厳密に型指定されたビジネス オブジェクトを返し、NextResult メソッドを呼び出してデータ セット ポインターを移動してデータ セットを見つけます。例 1 は、複数の ArrayList の厳密に型指定されたオブジェクトを返す例を示しています。必要なデータのみをデータベースから返すと、サーバーのメモリ消費量を大幅に削減できます。
2. データのページング
ASP。 NET の DataGrid には、ページングという非常に便利な機能があります。 DataGrid でページングが許可されている場合、特定の時間に特定のページのデータのみがダウンロードされます。さらに、データ ページング用のナビゲーション バーがあり、特定のページを参照して 1 ページのみをダウンロードすることを選択できます。データを一度に。
ただし、小さな欠点があります。それは、すべてのデータを DataGrid にバインドする必要があることです。つまり、データ レイヤーはすべてのデータを返す必要があり、その後、DataGrid が現在のページに必要なデータをフィルターで除外して表示します。 DataGrid を使用してページ分割する必要がある 10,000 レコードの結果セットがある場合、DataGrid が 1 ページあたり 25 個のデータのみを表示すると仮定すると、リクエストごとに 9975 個のデータが破棄されることになります。各リクエストは非常に大きなデータセットを返す必要があるため、アプリケーションのパフォーマンスに大きな影響を与えます。
良い解決策は、ページング ストアド プロシージャを作成することです。例 2 は、Northwind データベースの注文テーブル用のページング ストアド プロシージャです。現在のページ番号と各ページに表示される項目の数を渡すだけで、ストアド プロシージャは対応する結果を返します。
サーバー側では、データのページングを処理するページング コントロールを特別に作成しました。ここでは、最初の方法を使用し、ストアド プロシージャで 2 つの結果セット (データ レコードの総数と必要な結果セット) を返しました。
返されるレコードの合計数は、実行されるクエリによって異なります。たとえば、where 条件によって返される結果セットのサイズが制限される場合があります。ページの総数はページング インターフェイスのデータ セット レコードのサイズに基づいて計算する必要があるため、結果セット内のレコード数を返す必要があります。たとえば、合計 1,000,000 レコードがある場合、where 条件を使用すると、1,000 レコードのみを返すようにフィルターできます。ストアド プロシージャのページング ロジックは、表示する必要があるデータを返すことを認識している必要があります。
3. 接続プール
TCP を使用してアプリケーションをデータベースに接続すると、費用がかかります (そして時間がかかります)。Microsoft 開発者は、接続プールを使用してデータベース接続を再利用できます。接続プールは、リクエストごとに TCP を使用してデータベースに接続するのではなく、有効な接続がない場合にのみ新しい TCP 接続を作成します。接続が閉じられると、その接続はプールに置かれ、データベースへの接続が維持されるため、データベースへの TCP 接続の数が減ります。
もちろん、閉じ忘れた接続に注意する必要があります。使用後はすぐに閉じる必要があります。私が強調したいのは、誰が何と言おうと、.net Framework の GC (ガベージ コレクター) は、接続オブジェクトの使用が終了した後、常に接続オブジェクトの Close メソッドまたは Dispose メソッドを呼び出して、接続を明示的に閉じます。 CLR が予想時間内に接続を閉じるとは期待しないでください。CLR は最終的にオブジェクトを破棄して接続を閉じますが、いつこれらの処理を実行するかはわかりません。
接続プールの最適化を使用するには、2 つのルールがあります。まず、接続を開いてデータを処理し、次に接続を閉じます。リクエストごとに複数回接続を開いたり閉じたりする必要がある場合は、常にサイド接続を開いてそれを各メソッドに渡すよりも優れています。次に、同じ接続文字列 (統合認証を使用する場合は同じユーザー ID) を使用します。同じ接続文字列を使用していない場合 (ログインしているユーザーに基づいた接続文字列を使用している場合など)、接続プールの最適化機能は活用されません。統合引数を使用している場合、ユーザー数が多いため、コネクションプールの最適化機能を最大限に活用できません。 .NET CLR はデータ パフォーマンス カウンターを提供します。これは、接続プールの追跡など、プログラムのパフォーマンス特性を追跡する必要がある場合に非常に役立ちます。
アプリケーションがデータベースなどの別のマシン上のリソースに接続するときは常に、リソースへの接続にかかる時間、データの送受信にかかる時間、戻る回数の最適化に重点を置く必要があります。 。アプリケーション内のすべてのプロセス ホップを最適化することが、アプリケーションのパフォーマンスを向上させるための出発点となります。
アプリケーション層には、データ層に接続し、対応するクラスのインスタンスにデータを転送し、ビジネス処理を行うためのロジックが含まれています。たとえば、Community Server では、フォーラムまたはスレッドのコレクションを組み立ててから、承認などのビジネス ロジックを適用する必要があります。さらに重要なのは、ここでキャッシュ ロジックを完了する必要があることです。
4.ASP。 NETキャッシュAPI
アプリケーションを作成する前に、最初に行う必要があるのは、アプリケーションで ASP.NET のキャッシュ機能を最大限に活用できるようにすることです。
コンポーネントを Asp.net アプリケーションで実行する場合は、プロジェクト内で System.Web.dll を参照するだけで済みます。次に、HttpRuntime.Cache プロパティを使用してキャッシュにアクセスします (Page.Cache または HttpContext.Cache を通じてアクセスすることもできます)。
データのキャッシュにはいくつかのルールがあります。まず、データは頻繁に使用される可能性があり、このデータをキャッシュすることができます。第 2 に、データのアクセス頻度が非常に高い、またはデータのアクセス頻度は高くないが、そのライフサイクルが非常に長いデータをキャッシュすることが最適です。 3 番目は、無視されがちな問題です。通常、X86 マシンではキャッシュするデータが 800M を超えると、メモリ オーバーフロー エラーが発生します。したがって、キャッシュには制限があります。つまり、キャッシュ セットのサイズを見積もって、キャッシュ セットのサイズを 10 未満に制限する必要があります。そうしないと、問題が発生する可能性があります。 Asp.net では、キャッシュが大きすぎる場合、特に大きな DataSet オブジェクトがキャッシュされている場合、メモリ オーバーフロー エラーが報告されます。
ここでは、理解する必要がある重要なキャッシュ メカニズムをいくつか紹介します。まず、キャッシュは「最も最近使用された」原則 (最も最近使用されたアルゴリズム) を実装しており、キャッシュが少ない場合は、不要なキャッシュを自動的に強制的にクリアします。第 2 に、「条件付き依存関係」の強制削除 (有効期限依存関係) の原則です。条件には、時間、キーワード、ファイルを指定できます。条件としての時間は最も一般的に使用されます。 asp.net2.0 では、より強力な条件が追加されました。これはデータベース条件です。データベース内のデータが変更されると、キャッシュは強制的にクリアされます。データベースの条件依存関係の詳細については、MSDN マガジン 2004 年 7 月号の Dino Esposito の最先端コラムを参照してください。 Asp.net のキャッシュ アーキテクチャを次の図に示します。
5. リクエスト前キャッシュ
前に、一部の場所でわずかなパフォーマンスの向上を実現しただけでも、事前リクエスト キャッシュを使用してプログラムのパフォーマンスを向上させることが非常に気に入っていると述べました。
キャッシュ API はデータを一定期間保存するように設計されていますが、リクエスト前キャッシュは特定のリクエストのコンテンツを一定期間保存するだけです。特定のリクエストのアクセス頻度が高く、このリクエストでデータの抽出、適用、変更、更新が 1 回だけで済む場合。その後、リクエストを事前にキャッシュできます。例を挙げて説明しましょう。
CS フォーラム アプリケーションでは、各ページのサーバー コントロールには、スキンを決定したり、使用するスタイル シートやその他のパーソナライズされたものを決定したりするためのカスタマイズされたデータが必要です。ここでのデータの中には、長期間保存する必要がある場合もありますが、そうでない場合もあります。たとえば、コントロールのスキン データは 1 回適用するだけで、常に使用できます。
要求前キャッシュを実装するには、Asp.net の HttpContext クラスを使用します。HttpContext クラスのインスタンスは要求ごとに作成され、要求中のどこでも HttpContext.Current プロパティを通じてアクセスできます。 HttpContext クラスには Items コレクション プロパティがあり、すべてのオブジェクトとデータはこのコレクションに追加され、リクエスト中にキャッシュされます。 Cache を使用して頻繁にアクセスされるデータをキャッシュするのと同じように、HttpContext.Items を使用して各リクエストで使用される基本データをキャッシュできます。その背後にあるロジックは単純です。HttpContext.Items にデータを追加し、そこからデータを読み取ります。
6. バックグラウンド処理
上記の方法を使用すると、アプリケーションは非常に高速に実行されるはずです。しかし、ある時点で、プログラム内のリクエストで非常に時間のかかるタスクが実行される可能性があります。メールの送信や入稿データの正当性の確認等。
asp.net フォーラム 1.0 を CS に統合したとき、新しい投稿の送信が非常に遅くなることがわかりました。新しい投稿が追加されるたびに、アプリケーションはまずその投稿が重複しているかどうかを確認し、次に「badword」フィルターを使用してフィルターし、画像添付コードを確認し、投稿にインデックスを付けて、適切なキューに追加して検証する必要があります。添付ファイルを作成し、最後に電子メールを購読者のメールボックスに送信します。明らかに、これは大変な作業です。
その結果、メールのインデックス作成と送信に多くの時間が費やされることになります。投稿のインデックス作成は時間のかかる操作であり、購読者に電子メールを送信するには、SMTP サービスに接続してから各購読者に電子メールを送信する必要があります。購読者の数が増えると、電子メールの送信にかかる時間も長くなります。
メールのインデックス作成と送信は、リクエストごとにトリガーする必要はなく、一度に 25 件のメールだけを送信するか、すべての新しいメールを 5 分ごとに送信して、これらの操作をバッチで処理したいと考えています。同じコードをデータベース プロトタイプ キャッシュとして使用することにしましたが、失敗したため、VS.NET 2005 に戻る必要がありました。
System.Threading 名前空間の下に Timer クラスがあります。このクラスは非常に便利ですが、それを知っている人はほとんどおらず、Web 開発者でもさらに少数です。このクラスのインスタンスを作成すると、Timer クラスは指定された時間ごとにスレッド プール内のスレッドから指定されたコールバック関数を呼び出します。これは、リクエストがない場合でも ASP.NET アプリケーションを実行できることを意味します。これは後で対処する解決策です。インデックス作成と電子メール送信の作業を、リクエストごとに実行するのではなく、バックグラウンドで実行することができます。
バックグラウンド実行テクノロジには 2 つの問題があります。1 つは、アプリケーション ドメインがアンインストールされると、Timer クラスのインスタンスが実行を停止することです。つまり、コールバック メソッドは呼び出されません。また、CLR の各プロセスでは多数のスレッドが実行されているため、Timer を実行するためのスレッドを取得するのが困難、または実行できても遅延が発生します。 Asp.net レイヤーでは、プロセス内のスレッド数を減らすために、この手法の使用をできるだけ少なくするか、要求がスレッドのごく一部のみを使用できるようにする必要があります。もちろん、非同期作業が多い場合にのみ使用できます。
ここにコードを投稿するのに十分なスペースがありません。サンプル プログラムはhttp://www.rob-howard.net/からダウンロードできます。Blackbelt TechEd 2004 サンプル プログラムをダウンロードしてください。
7. ページ出力キャッシュとプロキシ サービス
Asp.net はインターフェイス層 (またはそうあるべき) であり、ページ、ユーザー コントロール、サーバー コントロール (HttpHandlers および HttpModules)、およびそれらが生成するコンテンツが含まれています。 HTML、xml、imgae、またはその他のデータを出力する Asp.net ページがあり、コードを使用して要求ごとに同じ出力コンテンツを生成する場合は、ページ出力キャッシュの使用を検討する必要があります。
これは、次のコード行をページにコピーするだけで実行できます。
<%@ PageOutputCache VaryByParams=”none” 期間=”60” %>
最初のリクエストで生成されたページを効果的に使用してキャッシュされたコンテンツを出力し、60 秒後にページ コンテンツを再生成できます。このテクノロジーは実際には、低レベルのキャッシュ API を使用して実装されています。前述の VaryByParams パラメーターなど、ページ出力キャッシュ用に構成できるパラメーターがいくつかあります。このパラメーターは、HTTP Get または Http Post 要求モードで出力をキャッシュするタイミングを指定することもできます。たとえば、このパラメーターを VaryByParams="Report" に設定すると、default.aspx?Report=1 またはdefault.aspx?Report=2 で要求された出力がキャッシュされます。パラメータの値は、セミコロンで区切って複数のパラメータにすることができます。
多くの人は、ページ出力キャッシュを使用すると、ASP.NET が HTTP ヘッダー セット (HTTP ヘッダー) を生成し、それをダウンストリーム キャッシュ サーバーに保存することを認識していません。この情報は、Microsoft インターネット セキュリティと高速化に使用できます。サーバーの応答速度。 HTTP キャッシュ ヘッダーがリセットされると、要求されたコンテンツはネットワーク リソースにキャッシュされ、クライアントがコンテンツを再度要求すると、オリジン サーバーからコンテンツを取得するのではなく、キャッシュから直接コンテンツを取得します。
ページ出力キャッシュを使用してもアプリケーションのパフォーマンスは向上しませんが、キャッシュされたページ コンテンツがサーバーからロードされる回数は減少します。もちろん、これは匿名ユーザーがアクセスできるページをキャッシュする場合に限定されます。ページがキャッシュされると、認証操作は実行できなくなるためです。
8. IIS6.0のカーネルキャッシュを使用する
アプリケーションが IIS 6.0 (Windows Server 2003) で実行されていない場合、アプリケーションのパフォーマンスを向上させるための優れた方法がいくつか失われています。 7 番目の方法では、ページ出力キャッシュを使用してアプリケーションのパフォーマンスを向上させる方法について説明しました。 IIS5.0 では、IIS に要求が来ると、IIS はそれを asp.net に転送します。ページ出力キャッシュが適用されると、ASP.NET の HttpHandler が要求を受け取り、HttpHandler がキャッシュからコンテンツを転送します。取り出して返却してください。
IIS6.0 を使用している場合、IIS6.0 にはカーネル キャッシュと呼ばれる非常に優れた機能があり、asp.net プログラムのコードを変更する必要はありません。 asp.net がキャッシュされた要求を受信すると、IIS のカーネル キャッシュはキャッシュからそのコピーを取得します。ネットワークからリクエストが来ると、カーネル層はリクエストを取得します。リクエストがキャッシュされている場合は、キャッシュされたデータを直接返します。これで完了です。つまり、IIS カーネル キャッシュを使用してページ出力をキャッシュすると、パフォーマンスが大幅に向上します。 VS.NET 2005 用の asp.net を開発していたとき、私は asp.net のパフォーマンスを特に担当していたプログラム マネージャーで、すべての日次レポート データを調べ、カーネル モデル キャッシュを使用した結果を見つけました。最速。これらに共通する特徴は、ネットワークの要求と応答が大きいにもかかわらず、IIS が CPU リソースの 5% しか使用しないことです。これはすごいですね。 IIS 6.0 を使用する理由はたくさんありますが、カーネル キャッシュが最適です。
9. Gzipでデータを圧縮する
CPU 使用率が高すぎる場合を除き、サーバーのパフォーマンスを向上させるテクニックを使用する必要があります。 gzip を使用してデータを圧縮すると、サーバーに送信するデータ量が削減され、ページの実行速度が向上し、ネットワーク トラフィックも削減されます。データをより適切に圧縮する方法は、送信するデータと、クライアントのブラウザがそれをサポートしているかどうかによって異なります (IIS は gzip 圧縮されたデータをクライアントに送信し、クライアントはそれを解析するために gzip をサポートしている必要があります、IE6.0 および Firefox)。こうすることで、サーバーは 1 秒あたりにより多くのリクエストに応答できるようになり、応答で送信されるデータの量も減り、より多くのリクエストを送信できるようになります。
良いニュースです。gzip 圧縮は IIS6.0 に統合されており、IIS5.0 の gzip よりも優れています。残念ながら、IIS 6.0 で gzip 圧縮を有効にするために、IIS 6.0 のプロパティ ダイアログで設定することはできません。 IIS 開発チームは gzip 圧縮機能を開発しましたが、管理者が管理者ウィンドウでこの機能を簡単に有効にできるようにすることを忘れていました。 gzip 圧縮を有効にするには、IIS6.0 xml 構成ファイル内の構成のみを変更できます。
この記事を読むだけでなく、Brad Wilson が書いた記事 <<IIS6 Compression>> ( http://www.dotnetdevs.com/articles/IIS6compression.aspx ) も読まなければなりません。基礎知識を紹介する記事もあります。 IIS で ASPX 圧縮を有効にします。ただし、IIS6 では動的圧縮とカーネル キャッシュは相互に排他的であることに注意してください。
10. サーバー コントロールの ViewState
ViewState は、ページの生成に使用される状態値を非表示フィールドに保存するために使用される asp.net の機能です。ページがサーバーにポストバックされると、サーバーは ViewState 内のデータを解析、検証、および適用して、ページのコントロール ツリーを復元します。 ViewState は、Cookie やサーバー メモリを使用せずにクライアントの状態を保持できる非常に便利な機能です。ほとんどのサーバー コントロールは ViewState を使用して、ページ上でユーザーと対話する要素の状態値を保持します。たとえば、ページング用に現在のページのページ番号を保存します。
ViewState を使用すると、いくつかの悪影響が生じます。まず、サーバーの応答時間とリクエスト時間が増加します。次に、ポストバックごとにデータのシリアル化と逆シリアル化にかかる時間が追加されます。最後に、サーバー上のメモリもより多く消費します。
多くのサーバー コントロールは、よく知られている DataGrid などの ViewState を使用する傾向がありますが、場合によっては ViewState を使用する必要がありません。 ViewState はデフォルトで有効になっています。ViewState を使用したくない場合は、コントロール レベルまたはページ レベルで無効にすることができます。コントロールでは、EnableViewState プロパティを False に設定するだけで済みます。ページ内で設定して、その範囲をページ全体に拡張することもできます。
<%@ ページ EnableViewState=”false” %>
ページがポストバックを必要としない場合、またはページが要求されるたびにコントロールを使用してレンダリングされるだけの場合。ページ レベルで ViewState をオフにする必要があります。
要約する
高パフォーマンスの ASP.NET アプリケーションの作成を向上させるのに役立つと思われるヒントをいくつか紹介します。この記事で説明した ASP.NET のパフォーマンスを向上させるためのヒントは単なる出発点にすぎません。詳細については、「ASP の改善」を参照してください。 NET「パフォーマンス」本。自分自身の実践を通じてのみ、プロジェクトに最も役立つテクニックを見つけることができます。ただし、これらのヒントは開発過程のガイドとして役立ちます。ソフトウェア開発では、プロジェクトごとに異なるため、これらはどれも絶対に役に立ちません。
