django-test-profiling

Django テストのプロファイリング

Django のテストスイートを高速化するために変更する前に、このスキルを使用してください。どの最適化に取り組む価値があるかは測定によって判断します。そうしないと、起動、データベースのセットアップ、フィクスチャの構築、または一部の遅いテストに本当のコストがかかっているのに、影響の小さい設定に時間を費やしてしまいがちです。

測定ワークフロー

1. 実行全体のウォールクロック時間のベースラインを取得します。

   • Python の起動、Django のインポート時間、テストの検出、データベースのセットアップ、ティアダウンが含まれるため、シェルのタイミング測定を優先します。
   • 正確なコマンド、環境、実行回数を記録します。

2. 可能であれば、フレームワークの各フェーズを分けて確認します。

   • Django のランナーでは、--timing を使用してデータベースのセットアップとティアダウンを確認します。
   • pytest では、シェルのタイミング測定と pytest --durations を比較します。

3. 最も遅いテストを特定します。

   • pytest-django では、まず pytest --durations 20 を実行します。
   • Django のランナーでは、プロジェクトに既存のものがない場合に限り、既存の遅いテスト用プラグインまたは簡単なカスタムランナーを使用します。

4. 時間のかかっている箇所がわかってから、プロファイリングします。

   • オーバーヘッドの小さい実行全体の概要を得るため、まず py-spy を使用します。
   • 網羅的な Python の呼び出しデータが必要な場合は、cProfile を使用します。

5. 結果を、優先順位を付けたアクションリストにまとめます。

   • コストがかかっている箇所が、起動、データベースの作成、繰り返されるセットアップ、テストデータ、クエリ数、I/O、キャッシュ／ファイル／ストレージへのアクセス、特定のテスト本体のどれなのかを特定します。
   • 次の手順に適したスキルがあれば、django-test-performance、django-test-data、または django-test-parallelization に引き継ぎます。

コマンド

time python manage.py test
python manage.py test --timing
pytest --durations 20

プロファイリングコマンドのバリエーションと結果の解釈については、profiler-commands.md を参照してください。

判断ルール

• シェルのタイミング測定を、ユーザーが実際に体感する実行時間の基準として扱います。
• データベースのセットアップまたはティアダウンが大きな割合を占める可能性がある場合は、Django の --timing を使用します。
• 疑わしく見えるテストではなく、測定で最も遅いと判明したテストから最適化します。
• 実行時間のばらつきが通常のローカル実行の妨げになる場合は、CI ログに記録します。
• テストランナーが子プロセスを使用する場合は、py-spy --subprocesses を使用します。
• cProfile の結果は、まず累積時間で並べ替えます。呼び出し元の連鎖を把握してから、自己時間を確認します。

よくある間違い

• フレームワークの最後に表示される「X 秒で実行」という行を、実行時間全体だと信じる。
• Django ランナーの時間と pytest の時間が、同じフェーズを計測しているかのように比較する。
• 遅いテストを特定する前に、すべてをプロファイリングする。
• 並べ替えていない cProfile の結果を読み、インポート処理の内部を追いかける。
• サンプリングプロファイルですべての短いホットパスを検出できると期待する。
• テストからヘルパーが何回呼び出されるかを確認せずに、そのヘルパーを最適化する。

検証

結果を報告する前に、以下を含めます。

• 正確なベースラインコマンドと、測定したウォールクロック時間。
• 最も遅いテストまたは最も時間のかかるフェーズ。
• 使用したプロファイラーがあれば、その種類と、適切だった理由。
• 期待される効果の大きい順に並べた、実用的な次のアクション上位 3 件。