パフォーマンス テストに関する推奨事項
この Power Platform Well-Architected パフォーマンス効率チェックリストのレコメンデーションに適用されます:
| PE:05 | パフォーマンスをテストします。 運用環境に一致する環境で定期的なテストを実行します。 結果をパフォーマンス目標およびパフォーマンス ベンチマークと比較します。 |
|---|
このガイドでは、テストに関する推奨事項について説明します。 パフォーマンス テストは、さまざまなシナリオでワークロードの機能を評価するのに役立ちます。 ワークロードの応答時間、スループット、リソース使用率、および安定性をテストして、ワークロードがパフォーマンス要件を満たしていることを確認します。
テストはパフォーマンスの問題を防ぐのに役立ちます。 また、ワークロードがサービス レベル アグリーメントを満たしていることを確認するのにも役立ちます。 パフォーマンス テストを行わないと、ワークロードのパフォーマンス低下が発生する可能性がありますが、これは多くの場合、防ぐことが可能です。 ワークロードのパフォーマンスは、パフォーマンス目標や確立されたベースラインから逸脱する可能性があります。
定義
| 任期 | Definition |
|---|---|
| カオス テスト | ランダムで予測不可能な障害や中断を意図的に導入することで、システムの回復力と安定性をテストすることを目的としたパフォーマンス テスト。 |
| 負荷テスト | 通常の負荷と高負荷の下でのシステム パフォーマンスを測定するパフォーマンス テスト。 |
| パフォーマンス ベースライン | テストによって検証された、通常の条件下でのワークロードの動作を表す一連のメトリック。 |
| ストレス テスト | システムが壊れるまで過負荷をかけるパフォーマンス テスト。 |
| 合成テスト | アプリケーションでのユーザー要求をシミュレートするパフォーマンス テスト。 |
主要な設計戦略
パフォーマンス テストは、ワークロードに関する測定可能なデータを収集するのに役立ちます。 早期にテストを実行すると、適切な仕様に合わせてワークロードを構築できます。 したがって、開発ライフサイクルのできるだけ早い段階でパフォーマンス テストを実施してください。 早期テストにより、運用に移行する前にパフォーマンスの問題を検出して修正できます。 運用コードの準備がまだできていない場合は、概念実証 (POC) を使用できます。
以前のシステムからデータを移行し、移行を特定の時間枠内に完了する必要がある場合、パフォーマンス テストにはデータ移行のパフォーマンスの測定を含める必要があります。
テストを準備する
パフォーマンス テストの準備とは、パフォーマンス テストを効果的に実行するために必要なリソース、構成、テスト シナリオを設定および配置することを指します。 優れたパフォーマンス テストでは、ユーザーが実際にソリューションをどのように使用するかをシミュレートする必要があります。 また、ソリューションがパフォーマンス目標を満たしているかどうかを検証するのにも役立ちます。
受け入れ基準を定義する
受け入れ基準では、ワークロードが受け入れ可能または成功と見なされるために満たす必要があるパフォーマンス要件を指定します。 パフォーマンス目標と一致する基準を定義します。
パフォーマンス目標を確認します。 パフォーマンス目標は、ワークロードに目的のパフォーマンス レベルを定義します。 ワークロードに対して確立されたパフォーマンス目標を確認します。 パフォーマンス目標は、応答時間、スループット、リソース使用率、またはその他の関連するパフォーマンス指標を含むメトリックです。 たとえば、応答時間を 2 秒未満など、特定のしきい値未満にするという目標を設定できます。
受け入れ基準を定義します。 パフォーマンス目標を、ワークロードのパフォーマンスを評価するために使用できる特定の受け入れ基準に変換します。 たとえば、応答時間のパフォーマンス目標が 2 秒以下であるとします。 受け入れ基準は、ワークロードの平均応答時間は 2 秒未満であること とすることができます。 これらの受け入れ基準を使用して、ワークロードが目的のパフォーマンス レベルを満たしているかどうかを判断します。
受け入れ基準を定義するときは、ユーザーとその期待に焦点を当てることが重要です。 受け入れ基準は、提供された作業がユーザーのニーズと要件を満たしていることを確認するのに役立ちます。 ユーザーの視点を受け入れ基準に組み込む場合は、次の点を考慮してください:
ユーザー ペルソナ: ソリューションを同時に使用するユーザーの数とタイプを把握します。 さまざまなロール、場所、セキュリティ構成、データ セット、アクティビティを表すユーザー ペルソナを定義します。
ユーザー要件: ワークロードに対するユーザーのニーズと目標を把握します。 これらの要件を満たすためにワークロードをどのように実行するかを検討します。 ユーザーが典型的な日に行うアクションを反映した日常のシナリオを定義します。 ピーク負荷と通常負荷のシナリオを含めます。
ユーザー エクスペリエンス: 目的のユーザー エクスペリエンスをキャプチャする受け入れ基準を定義します。 応答時間、ユーザビリティ、アクセシビリティ、全体的な満足度などの要素を含めます。
機能要件: ユーザーがワークロードで期待する特定の機能に対応します。 これらの機能要件に関する受け入れ基準を定義して、それらが満たされていることを確認できるようにします。 各シナリオで現実的なデータ量を使用します。 ユーザーが必要とするよりも多くまたは少なくデータを使用しないでください。
インフラストラクチャ要件: 各シナリオの現実的なインフラストラクチャ要件を定義します。 たとえば、ユーザーが接続性の悪いモバイル デバイスからソリューションにアクセスする場合は、そのような条件下でソリューションをテストします。
ユース ケース: ユーザーが遭遇する可能性のあるさまざまなシナリオやユース ケースを検討します。 これらのユースケースに基づいて受け入れ基準を定義し、実際の状況でワークロードのパフォーマンスを検証します。
受け入れしきい値を設定します。 ワークロードがパフォーマンス目標を満たしているかどうかを示す、受け入れ基準内のしきい値を決定します。 これらのしきい値は、各メトリックのパフォーマンスの許容範囲を定義します。 たとえば、応答時間の受け入れ基準が 2 秒未満であるとします。 しきい値を 2.5 秒に設定できます。 このレベルでは、応答時間が 2.5 秒を超えるとパフォーマンスの問題と見なされます。
合格基準を定義します。 ワークロードがパフォーマンス テストに合格したか失敗したかを判断するための基準を確立します。 合格とは、すべての受け入れ基準を満たすか、一定の割合を達成することと定義できます。
テストの種類を選択する
適切なタイプのパフォーマンス テストを選択するには、テストを受け入れ基準に合わせることが重要です。 受け入れ基準は、要件またはバグ修正が完了と見なされるために満たす必要がある条件を定義します。 パフォーマンス テストの目的は、ワークロードがこれらの受け入れ基準を満たし、指定された条件下で期待どおりに動作するかどうかを確認することです。 パフォーマンス テストの種類を受け入れ基準に合わせると、基準で定義されたパフォーマンスの期待値を満たすことにテストが重点を置くことができます。
受け入れ基準を理解する。 要件またはバグ修正の受け入れ基準を確認します。 基準は、満たすべき特定の条件と機能の概要を示します。
関連するパフォーマンス指標を特定する。 受け入れ基準に基づいて、目的の結果を達成するために重要なパフォーマンス指標を決定します。 たとえば、受け入れ基準が応答時間に重点を置いている場合は、負荷テストを優先することが適切な場合があります。
適切なテストの種類を選択する。 利用可能なテストの種類を評価し、特定したパフォーマンス指標と受け入れ基準に最も合致するものを選択します。
次の表に、テストの種類とそのユース ケースの例を示します。
| 検査の種類 | プロパティ | 使用例 |
|---|---|---|
| 負荷テスト | 現実的なユーザー負荷をシミュレートして、予想されるピーク ワークロード下でのワークロードのパフォーマンスを測定します。 | 負荷許容度を判断します。 |
| ストレス テスト | ワークロードを通常の限界を超えてプッシュし、限界点を特定して回復能力を測定します。 | 回復力と堅牢性を判断します。 |
| ソーク テスト (耐久性テスト) | 長期間にわたって持続的な高負荷の状態でワークロードを実行し、パフォーマンスの低下、メモリ リーク、またはリソースの問題を特定します。 | 時間の経過に伴う安定性と信頼性を評価します。 |
| スパイク テスト | ユーザー負荷の突然の増加をシミュレートして、ワークロードが需要の急激な変化をどのように処理するかを評価します。 | ピーク時にパフォーマンスをスケーリングおよび維持する能力を測定します。 |
| 互換性テスト | さまざまなプラットフォーム、ブラウザー、デバイスでワークロードのパフォーマンスをテストします。 | さまざまな環境で一貫したパフォーマンスを確保するのに役立ちます。 |
ワークロードの特性と要件に基づいて、選択したテストの種類に優先順位を付けます。 パフォーマンス指標の重要性、ユーザーの期待、ビジネスの優先順位、既知の問題や脆弱性などの要素を考慮します。
テスト ツールを選択する
実行するパフォーマンス テストの種類に基づいて適切なツールを選択します。 テスト環境のインフラストラクチャ、リソース、制約を評価します。 目的のテストの種類をサポートし、監視、測定、分析、レポートに必要な機能を提供するテスト ツールを選択します。
アプリケーション パフォーマンス監視 (APM) ツールは、アプリケーションに関する詳細な分析情報を提供する、不可欠なテスト ツールです。 個々のトランザクションを追跡し、さまざまなワークロード サービスを通じてそのパスをマップするのに役立ちます。 テスト後、APM ツールを使用してテスト データを分析し、パフォーマンス ベースラインと比較する必要があります。
プロファイル ツールを使用して、コードにおけるパフォーマンスのボトルネックを特定します。 プロファイルは、最も多くのリソースを消費し、最適化が必要なコード領域を特定するのに役立ちます。 コードのさまざまな部分の実行時間とメモリ使用量に関する分析情報を提供します。
次の手順は、適切なテスト ツールの選択に役立ちます:
テスト要件を特定する。 パフォーマンス テストの具体的な要件を理解することから始めます。 さまざまな要因を検討してください:
- ワークフローの種類
- 応答時間やスループットなどの測定対象のパフォーマンス指標
- ワークロード アーキテクチャの複雑さ
- クラウドベース、オンプレミス、ハイブリッドなどのテスト環境
テスト ツールを調査する。 調査を実施して、要件に適合するパフォーマンス テスト ツールを特定します。 市場で入手可能な商用ツールやオープンソース ツールを検討してください。 負荷テストやストレス テストなど、目的の種類のパフォーマンス テストをサポートし、パフォーマンス指標を測定する機能を提供するツールを調べます。
ツールの機能を評価する。 各テスト ツールが提供する機能を評価します。 現実的なユーザー行動のシミュレーションや、大量のユーザー負荷を処理するためのスケーラビリティなどの機能を調べます。 さまざまなプロトコルとテクノロジーのサポート、他のテスト ツールやフレームワークとの統合、レポート機能と分析機能を検討してください。
互換性と統合を検討する。 テスト ツールと既存のインフラストラクチャおよびテクノロジーとの互換性を判断します。 ツールをテスト環境に簡単に統合でき、監視と分析に必要なワークロードと通信できることを確認します。
コストとライセンスを評価する。 テスト ツールに関連するコスト構造とライセンス条項を評価します。 初期投資、メンテナンス コスト、サポート コストなどの要素を考慮します。 また、ユーザー数または仮想ユーザー数に応じてその他のライセンス要件も考慮します。
POC を実施する。 評価に基づいて最も適切と思われるツールをいくつか選択します。 小規模な POC を実施して、特定のテスト シナリオにおけるツールのユーザビリティ、機能、有効性を検証します。
サポートとトレーニングを検討する。 ツールのベンダーまたはコミュニティが提供するサポートとトレーニングのレベルを評価します。 テスト プロセス中に発生する可能性のある課題や問題に対処するために、ドキュメント、チュートリアル、およびテクニカル サポート チャネルが利用可能かどうかを確認します。
テスト シナリオを作成する
テスト シナリオの作成とは、ワークロードのパフォーマンスをテストするのに適した特定の状況または条件を設計するプロセスを指します。 テスト シナリオは、現実的なユーザー行動とワークロード パターンをエミュレートするために作成されます。 これらのシナリオは、パフォーマンス テスターがさまざまな条件下でワークロードがどのように実行されるかを評価する方法を提供します。
テスト シナリオでは、コンカレンシーのユーザー アクセス、ピーク負荷期間、特定のトランザクション シーケンスなど、さまざまなワークロード パターンを再現できます。 さまざまなワークロード パターンでワークロードをテストすることで、パフォーマンスのボトルネックを特定し、リソースの割り当てを最適化できます。
ユーザーの行動を定義する。 ユーザーがワークロードを操作するときに実行する手順とアクションを特定することで、現実的なユーザー行動とワークロード パターンをエミュレートします。 サインイン、検索の実行、フォームの送信、特定の機能へのアクセスなどのアクティビティを検討してください。 各シナリオを、ユーザーのワークロードとのやり取りを表す特定のステップとアクションに分割します。 ページ間の移動、トランザクションの実行、ワークロードのさまざまな要素との対話などを含めることができます。
データの関与を判断する。 テスト シナリオを実行するために必要なテスト データを特定します。 さまざまなシナリオ、ユーザー プロファイル、またはデータ ボリュームを表す現実的なデータ セットの作成または生成を含めることができます。 包括的なパフォーマンス評価を提供するために、テスト データが多様であり、さまざまなユース ケースをカバーしていることを確認します。
テスト スクリプトを設計する。 定義されたテスト シナリオの実行を自動化するテスト スクリプトを作成します。 テスト スクリプトは通常、一連のアクション、HTTP 要求、またはワークロード API やユーザー インターフェイスとのやり取りで構成されます。 パフォーマンス テスト ツールまたはプログラミング言語を使用し、パラメーター化、相関関係、動的データ処理などの要素を考慮してスクリプトを記述します。 テスト スクリプトの正確性と機能性を検証します。 スクリプト エラー、アクションの欠落または誤り、データ関連の問題などの問題をデバッグします。 テスト スクリプトの検証は、正確で信頼性の高いパフォーマンス テストの実行を保証するために不可欠です。
テスト変数とパラメーターを構成する。 テスト スクリプト内で変数とパラメーターを構成して、変動性を導入し、実際のシナリオをシミュレートします。 さまざまなユーザー行動やワークロードの応答を模倣するために、ユーザー資格情報、入力データ、ランダム化などのパラメーターを含めます。
繰り返しスクリプトを改善する。 フィードバック、テスト結果、または要件の変更に基づいて、テスト スクリプトを継続的に改善および強化します。 スクリプト ロジック、パラメーター化、エラー処理を最適化するか、追加の検証とチェックポイントを追加することを検討してください。
テスト環境を構成する
テスト環境の構成とは、運用環境によく似た環境を作成するために必要なインフラストラクチャ、ソフトウェア、およびネットワーク構成を設定するプロセスを指します。
パフォーマンス効率を向上させる方法でテスト環境を設定するには、構成プロセスに次の手順を含めます:
運用環境をミラーリングする。 運用環境によく似たテスト環境を設定します。 環境設定とリージョン、ネットワーク設定、セキュリティ設定、データ ソース、統合などの要素を考慮します。 目標は、パフォーマンス テストの結果が実際の状況を表していることを確認することです。
十分なリソースをプロビジョニングする。 テスト環境にストレージ キャパシティなどの適切なリソースを割り当てます。 利用可能なリソースが予想されるワークロードを処理でき、正確なパフォーマンス測定を提供できることを確認します。
ネットワーク条件を再現する。 実際のワークロードの展開中に予想されるネットワーク条件を再現するように、テスト環境でネットワーク設定を構成します。 帯域幅、待機時間、ネットワーク プロトコルを含める必要があります。
依存関係をインストールして構成する。 AppSource からアプリと、ワークロードを正しく実行するために必要なその他の依存関係をインストールします。 これには、予想される運用構成でサード パーティ サービスを構成することが含まれます。
トレードオフ: 個別のテスト環境の維持、データの保存、ツールの使用、テストの実行には、それぞれ費用がかかります。 パフォーマンス テストのコストを把握し、支出を最適化する方法を見つけます。
リスク: 生産データには機密情報が含まれている可能性があります。 堅牢なスクラブおよびマスキング戦略がなければ、運用データをテストに使用するときに機密データが漏洩するリスクがあります。
テストを実行する
選択したテスト ツールを使用してパフォーマンス テストを実行します。 テストには、パフォーマンス指標の測定と記録、正常性の監視、発生したパフォーマンスの問題のキャプチャが含まれます。
応答時間、スループット、その他の関連指標などのパフォーマンス指標を監視および収集します。
定義されたテスト シナリオを使用して、ワークロードを予想される負荷の下に置きます。 これらのさまざまな負荷条件下でテストを実施します。 たとえば、通常レベル、ピーク レベル、ストレス レベルなどのレベルを使用して、さまざまなシナリオでのワークロードの動作を分析します。
パフォーマンス テストを計画および実行するときは、多くの場合、Microsoft Cloud が共有インフラストラクチャを使用して、顧客の資産や他の顧客に属する資産をホストしていることを覚えておくことが重要です。 意図しない結果を避けるためにテストを制限します。
結果を文書化する
パフォーマンス テストの結果を明確かつ一貫して文書化します。 ドキュメントには次の内容が表示されます:
- ソリューションが各シナリオのパフォーマンス目標を満たしているかどうか
- 各テストをいつ、どのように実行したか
- テストしたソリューションのバージョン
- テスト中に発生したエラーや問題
- テスト後に行った変更や最適化
結果を分析する
テスト結果の分析には、パフォーマンス テストから収集されたデータとメトリックを調べて、ワークロードのパフォーマンスに関する分析情報を得ることが含まれます。 目標は、パフォーマンスの問題を特定し、フィードバックを使用してアプリケーション開発の優先順位を調整することです。
次のアクションは、テスト結果を分析するための重要な手順です。
パフォーマンス指標を確認します。 応答時間、スループット、エラー率、ネットワーク遅延など、パフォーマンス テスト中に収集したパフォーマンス指標を確認します。 これらのメトリックを分析して、ワークロードの全体的なパフォーマンスを把握します。
ボトルネックを特定する。 パフォーマンス指標を評価して、ボトルネックや非効率的なパフォーマンスの領域を特定します。 評価には、応答時間の長さ、リソースの制約、データベースの問題、ネットワークの遅延、スケーラビリティの制限などが含まれます。 これらのボトルネックの根本原因を特定することで、パフォーマンス改善の優先順位付けに役立ちます。
メトリックを関連付ける。 さまざまなパフォーマンス指標間のリレーションシップと相関関係を評価します。 たとえば、負荷やリソース使用率の増加が応答時間に与える影響を分析します。 これらの相関関係を把握することで、さまざまな条件下でのワークロードの動作に関する貴重な分析情報を得ることができます。 時間の経過に伴うパフォーマンス データのパターンと傾向を調べます。 さまざまな負荷レベルまたは特定の期間におけるパフォーマンスを分析します。 傾向の検出は、季節変動、ピークの使用時間、または繰り返し発生するパフォーマンスの問題を特定するのに役立ちます。
受け入れ基準を評価する。 再テストの結果を、事前定義された受け入れ基準およびパフォーマンス目標と比較します。 ワークロードが目的のパフォーマンス基準を満たしているかどうかを評価します。 ワークロードが受け入れ基準を満たしていない場合は、さらに調査して最適化を調整します。
分析を繰り返して改善する。 必要に応じて、その他の調整や改善を行います。 収集したデータとメトリックを使用して、特定のパフォーマンスの問題を診断します。 診断は、ワークロード コンポーネントのトレース、ログ ファイルの検証、リソース使用状況の監視、エラー メッセージの分析を含む場合があります。 データをさらに深く掘り下げて、パフォーマンスの問題の根本的な原因を把握します。
テスト結果の分析に基づいて、特定されたパフォーマンスの問題に優先順位を付け、必要な改善を実施します。 改善には、ロジックの最適化、クエリの調整、キャッシュ メカニズムの改善、ネットワーク構成の最適化などが含まれます。
ベースラインを確立する
ベースラインは、時間の経過に伴うパフォーマンス結果を比較するための参照ポイントを提供します。 ベースラインはワークロード パフォーマンスの意味のあるスナップショットである必要があります。すべてのテストをベースラインとして使用する必要はありません。
ワークロードの目標を考慮し、時間の経過とともに学習して最適化できるようにするパフォーマンス スナップショットを文書化します。 これらのベースライン測定値を将来のパフォーマンス テストのベンチマークとして使用し、低下や改善を特定するために使用します。
パフォーマンス テストのベースラインを確立し、それを将来のパフォーマンス テストのベンチマークとして使用するには、次の手順に従います:
パフォーマンス指標を特定する。 測定および追跡する特定のパフォーマンス指標を決定します。例には次のものがあります:
- 応答時間、つまりワークロードが要求に応答する速度。
- スループット、つまり単位時間あたりに処理される要求の数。
- ストレージ キャパシティの使用状況などのリソース使用率。
意味のある測定値を記録する。 テスト中に取得したパフォーマンス指標をベースライン測定値として記録します。 これらの測定値は、今後のパフォーマンス テストを比較する際の出発点を表します。
今後のテストを比較する。 後続のパフォーマンス テストでは、パフォーマンス指標を確立されたベースラインおよびしきい値と比較します。 比較することで、パフォーマンスの向上または低下を特定できます。
継続的にテストする
継続的なテストには、テストの継続的な監視と改善が含まれます。 継続的なテストは、一貫した許容レベルのパフォーマンスを維持するのに役立ちます。 ワークロードは、ベースラインと比較して、一貫した許容レベルのパフォーマンスを提供する必要があります。 パフォーマンスの許容範囲内で一貫したパフォーマンスを実現するには、時間の経過とともにワークロードを調整する必要があります。
いくつかの重要なプラクティスを以下に示します:
低下の限界を設定する。 時間の経過とともに許容されるパフォーマンス低下のレベルを指定する数値しきい値を定義します。 これらの制限を設定することで、パフォーマンスの変動を監視し、パフォーマンスが定義されたしきい値を下回ったときにアラートを受け取ることができます。
品質保証を含める。 1 秒あたりの最大要求数などのパフォーマンス要件を品質保証プロセスに組み込みます。 パフォーマンス要件を機能要件と同じレベルの重要性で扱います。 このプロセスは、ワークロードを運用に展開する前に、定義されたパフォーマンス要件を満たしていることを確認するのに役立ちます。
アラートを自動化する。 ライブ環境では、迅速な検出と応答が重要です。 パフォーマンス ベースラインを参照として使用する自動アラート システムを設定します。 パフォーマンスに大きな逸脱がある場合は、必要なチームに直ちに警告して対処します。
変更をテストする。 一部のパフォーマンス上の問題は、ライブ環境でのみ現れる可能性があります。 提案された変更に対して徹底的なテスト プラクティスを適用します。 コード インストルメンテーションを使用して、ホット パスなどのアプリケーションのパフォーマンス特性に関する分析情報を取得します。 このテストにより、導入された変更が許容限度を超えてパフォーマンスを低下させないことが保証されます。
Power Platform の促進
テストを実行する: Azure Pipelines を使用すると、パフォーマンス テストを CI/CD (継続的インテグレーション/継続的デリバリー) パイプラインに統合できるようになります。 パイプラインのステップとして負荷テストを組み込んで、アプリケーションのパフォーマンスとスケーラビリティを検証できます。
Power Apps テスト エンジン は、Power Apps でスタンドアロン キャンバス アプリをテストするために使用できる Power Platform CLI 内のコンポーネントです。
Azure Test Plans は、計画手動テスト、ユーザー受け入れテスト、探索的テスト、関係者からのフィードバックの収集に必要なすべての機能を提供する、使いやすいブラウザベースのテスト管理ソリューションです。
ワークロードに Azure リソースが含まれている場合は、Azure Chaos Studio と Azure Load Testing を使用してテストを実行できます。
開発中、開発者は Power Apps Monitor を使用して、問題の診断とトラブルシューティングを迅速に行い、より信頼性の高いアプリを構築することもます。 アプリの実行時に行われる重要な活動をすべて記録することにより、アプリについての詳細を把握できます。 Power Apps Monitor では、アプリに含まれているイベントや数式がどのように機能するかをよりよく理解できるため、パフォーマンスを向上させ、エラーや問題を特定することができます。
ワークロードに Microsoft Copilot Studio エージェントが含まれている場合は、Power CAT Copilot Studio キット を使用してエージェントとテストを構成できます。 Copilot Studio API (Direct Line) に対して個別のテストを実行することで、エージェントの応答が期待される結果と照らし合わせて評価されます。
結果を分析する: Azure Monitor は、クラウドおよびオンプレミスの環境からテレメトリを収集、分析、および応答するための包括的な監視ソリューションです。 Application Insights は、APM 機能を提供する Azure Monitor の拡張機能です。 Application Insights を使用すると、開発中、テスト中、および運用中にアプリケーションを監視できます。
関連情報
パフォーマンス効率チェックリスト
完全なレコメンデーションのセットを参照してください。