彼のブログ記事の1つで、このWebサイトの所有者は、読者にこの質問を投げかけました。「ソフトウェアを流れるすべてのクエリを自動的に測定していますよね?」
これはどうやるんですか?データベースに対してクエリを実行するコードのすべての行の後に、カウンターをインクリメントするコードの行が続きますか?または、アプリとDBの間にあり、これを行うツールはありますか?
彼のブログ記事の1つで、このWebサイトの所有者は、読者にこの質問を投げかけました。「ソフトウェアを流れるすべてのクエリを自動的に測定していますよね?」
これはどうやるんですか?データベースに対してクエリを実行するコードのすべての行の後に、カウンターをインクリメントするコードの行が続きますか?または、アプリとDBの間にあり、これを行うツールはありますか?
SQL Server Profilerは私の選択したツールですが、明らかにDBエンド専用です。
これは、クエリとパフォーマンスの最適化、およびデバッグのためであることに注意してください。これは、リソースを大量に消費する可能性があるため、常に実行し続けるツールではありません。
これを行うために、dynaTrace というソフトウェア製品を購入しました。これを行うために、バイト コード インストルメンテーション (.Net を使用するため、この場合は MSIL を使用しますが、Java も使用します) を使用します。基本的には、選択したメソッドとさまざまなフレームワーク メソッドの周りに計測を行い、各メソッドの実行にかかる時間をキャプチャします。
データベース呼び出しに関しては、(ADO.Net を介して) 行われた各呼び出しと呼び出しのパラメーターを実行時間と共に追跡します。次に、DB 呼び出しから移動し、プログラムがそこに到達するまでにたどった実行パスをたどることができます。パス内のすべてのメソッド呼び出し (インストルメント化したもの) が表示されます。それはかなり悪いです。
これはさまざまな方法で使用できますが、通常は、システムのさまざまなパスを介して負荷を提供する他の製品を使用した、ある種の負荷テスト シナリオで使用されます。次に、負荷がかかっている DB 呼び出しのリストを取得し、それらを確認できます。
また、1 回の呼び出しの実行だけでなく、その回数を評価して、1000 カットの死を防ぐこともできます。
Jeff が何を言おうとしていたのかは正確にはわかりませんが、データベースに対してクエリ パフォーマンス監視機能を使用することを彼は期待していると思います。
もう 1 つの方法は、コード内のデータベース接続にラッパーを使用することです。たとえば、Java では、すべてのクラスが使用する DataSource があると仮定すると、基になる DataSource を使用して Connection オブジェクトを作成する DataSource の独自の実装を作成できます。DataSource は、これらの接続を独自の Connection オブジェクトでラップする必要があります。これにより、それらを通過するデータを追跡できます。
すべてのデータベース作業に使用する C++ ラッパーがあります。そのラッパー (デバッグ モード) は、実行するすべてのステートメントに対して基本的に EXPLAIN QUERY PLAN を実行します。インデックスが使用されていないという応答が返ってきた場合は、アサートします。インデックスが使用されていることを確認する優れた方法 (ただし、デバッグ モードのみ)
アーキテクチャが適切に設計されている場合、すべてのデータアクセス呼び出しをインターセプトし、クエリの実行時間を測定するのはかなり簡単です。これを行う非常に簡単な方法は、DB呼び出しの周りにアスペクトを使用することです(言語/フレームワークがアスペクトプログラミングをサポートしている場合)。もう1つの方法は、すべての呼び出しをインターセプトし、実際のドライバーにリダイレクトして、クエリ時間の実行を測定する特別なドライバーを使用することです。
Perl の場合、DBI::Profile。