Djangoプロジェクトのテストの高速化

Djangoアプリケーションのテストの問題は、Habréを含むさまざまな記事で大きな注目を集めています。 それらのほぼすべてにおいて、テストの合格を高速化するためのメソッドとハックに少なくとも2、3の文が当てられているため、ここで根本的に新しいことを言うのは容易ではありません。



NetAngelsでほとんどの時間を費やしてきたホスティングコントロールパネルのプロジェクトでは、テスト中に120個のテーブルとフィクスチャからの約500個のオブジェクトがロードされます。 これは恐ろしいほど多くは言えませんが、すべてのテーブルを作成し、テストを実行するたびにインデックスを追加し、オブジェクトをロードすることは、特に1つまたは2つだけのテストを実行する場合は非常に面倒です。



猫の下では、以前に提案されたテストを高速化するためのいくつかの方法がやや簡潔にリストされており、最後に別の有用なレシピの詳細な説明がありますが、私は今、テスト実行の速度の問題をすでに完全に除去していることを願っています。



平均的なアプリケーションでは、原則として、ほとんどのブレーキはデータベースの操作に関連付けられます。 ほとんどすべての提案がこの特定のコンポーネントの最適化を目的としていることは驚くことではありません。



次に、データベースの操作は主にディスクサブシステムによって遅くなります。この負荷を何らかの方法で削減すると、パフォーマンスが大幅に向上すると想定するのは理にかなっています。

安全でないトランザクション設定

テストプロセス中に電気が突然失われ、データがディスクに完全に書き込まれない場合、誰も気にしません。 通常、データベースサーバーは、このようなイベントの悲しい結果を最小限に抑えるように構成されています。 テスト用に別のMySQLサーバーまたはPostgreSQLサーバーを使用する場合、設定を安全に安全に変更できます。



特に、MySQLの場合、以下を提供します。



[mysqld]

default-table-type=innodb

transaction-isolation=READ-COMMITTED

innodb_flush_log_at_trx_commit = 0

skip-sync-frm=OFF









PostgreSQLでは、同じ目的でpostgresql.confにfsync = off



オプションを追加することをお勧めfsync = off



ます。

ramdiskを使用する

より根本的なアプローチは、ディスクをまったく使用せず、代わりにRAM内のデータを操作することです。 一般的な原則は、tmpfsファイルシステムを使用して新しいパーティションを作成し、別のディレクトリにマウントしてから、すべてのデータベースファイルをこのディレクトリに作成することです。 追加のボーナスは、単にパーティションをアンマウントするとすべてのデータが削除されることです。

テスト用のSQLite

実際、Django開発者は、テストをできるだけ早く実行するために多くのことをすでに行っています。 特に、SQLiteをデータベースエンジンとして使用する場合、テスト中にデータベースがメモリに作成され（文字列 "：memory："がファイル名としてドライバに渡されます）、この方法だけでほとんどの問題を高速で解決できます。



ORM Djangoがデータベースの詳細を慎重に隠していないと不平を言うこともあるため、場合によっては、SQLiteで機能するコード（つまり、テストに合格したコード）が、それが存在するシステムにロールアウトすると突然壊れることがありますMySQLは動作します。 実際、これは時々起こりますが、原則として、あなたが何か「異常な」ことをしたという事実の結果です。例えば、QuerySet.extraメソッドを使用して手動でクエリを作成し始めました。 ただし、ほとんどの場合、そのようなことをすれば、これがどのように脅威になるかを知っています。

予備のSQLiteテストベースの作成

ご存知のように、テストを実行すると、Djangoは次の一連のアクションを実行します。



1.ユーザーの許可を得て、テストデータベースをクリアします（テストデータベースに何かがある場合）

2.テストデータベースにすべてのテーブルとインデックスを作成します

3. initial_dataという一連のフィクスチャをロードします

4.テストを1つずつ実行します

5.テスト中に作成されたすべてを削除します



データがメモリ内に存在する場合、最初と最後のステージは実行されない可能性がありますが、ステップ2と3にはかなりの時間がかかり、「コードを修正してテストを開始」という高速の反復が遅くなります。 明らかに、データベーススキーマとフィクスチャセットは、コードとテストよりもはるかに少ない頻度で変更されるため、データベースの絶え間ない作成を節約することには意味があります。 ちなみに、ステップ2と3は、syncdb管理コマンドの通常の実行です。



テストの実行を高速化する一般的なアプローチは、syncdbを手動で実行することです。本当に必要な場合にのみ、テストを開始するときに準備済みのデータベースをコピーするだけです。 SQLiteを使用すると、ファイルをコピーせずに実行できますが、「：memory：」でテストを操作する利点を失いたくありませんでした。



短い検索により、このケースの解決策が存在することが示されました。 SQLiteには「ホット」バックアップ用のインターフェイスがあり（大人の場合と同様）、事前に準備されたデータベースからそのようなコピーを名前がmemoryのデータベースに実行すると、まさに必要なものが得られます：初期化されたデータベースメモリ内のデータ。



実装の最初の難しさは、標準のPythonモジュールsqlite3がサポートしておらず、おそらくこのAPIをサポートしないことです。したがって、Pythonを使用してこのようなコピーを実行するには、APSW（Another Python SQLite Wrapper）というサードパーティモジュールを使用することをお勧めします。



2番目の難点は、メモリ内の新しいデータベース接続ごとに、データベースの独自のコピー（明らかに空）を作成するため、ORSWが使用するカーソルにAPSWによって初期化された接続を使用する方法を教える必要があることです。 幸いなことに、この場合にはハックが提供されます。sqlite3を使用して接続を作成するときに、ファイル名のある行の代わりに、apsw.Connectionオブジェクトを渡すことができます。



そのため、ソリューションは非常にシンプルに見えます。



1. 2つのASPW接続オブジェクトを作成します。1つは事前に準備されたデータベースを参照し、もう1つはメモリ内のデータベースを参照します。

2.ファイルからメモリにデータをコピーします。

3.「default」という名前のエイリアスのNAMEパラメーターには、メモリを参照するASPW接続を渡します。

4.カーソルを初期化し、テストを実行します。



データベースの作成は非常に簡単です。「quickstart」という名前のエイリアスをDATABASES settings.py変数に追加してから、. ./manage.py syncdb --database quickstart



実行する./manage.py syncdb --database quickstart



です。



これらのアクションを実行できるすべてのコードは、20行弱かかり、以下に示します。 動作させるには十分です



1. APSWをインストールします

2.コードを別のファイルにコピーして、プロジェクトに配置します

3. quickstartという名前のデータベースのsettings.DABABASESにエイリアスを追加します

4. ./manage.py syncdb --database quickstart



実行してデータベースを作成します

5.変数TEST_RUNNERを設定して、保存したばかりのオブジェクトのクラスを参照するようにします

6.簡単なテストを実行してみてください。

Copy Source | Copy HTML

1. インポート apsw
2. ジャンゴから 。 テスト .simple import DjangoTestSuiteRunner
3. django.db インポート接続から
5. クラス TestSuiteRunner （DjangoTestSuiteRunner）：
7. def setup_databases （self、** kwargs）：
8. quickstart_connection = connections [ 'quickstart' ]
9. quickstart_dbname = quickstart_connection.settings_dict [ 'NAME' ]
11. memory_connection = apsw.Connection（ '：メモリ：' ）
12. quickstart_connection = apsw.Connection（quickstart_dbname）
13. バックアップとして memory_connection.backup（ 'main' 、quickstart_connection、 'main' ） を使用します。
14. backup.doneではない場合：
15. backup.step（ 100 ）
17. connection = connections [ 'default' ]
18. connection.settings_dict [ 'NAME' ] = memory_connection
19. カーソル= connection.cursor（）
21. def teardown_databases （self、old_config、** kwargs）：
22. 合格する

その結果、1つのテストの実行時間が18秒から2秒に短縮されました。必要な回数だけテストを実行するのは非常に快適です。



同じコードですが、コメントと「テストでデータが食べられる可能性があります！」（テスト環境でのみ使用）という大胆な警告がgist.github.com/1044215で利用可能です。



これらの簡単な推奨事項により、コードをより速く、より効率的に、より確実に書くことができればと思います。

使用したソース

詳細およびその他の有用な情報については、データベースサーバーのドキュメントと次のソースを参照することをお勧めします。



-MySQLを使用したDjangoユニットテストの実行の高速化

-Innodbパフォーマンス最適化の基本

-SQLite Online Backup APIの使用

-PythonでSQLiteのバックアップを使用する方法