特定のデータベース処理がボトルネックとなっているように思われる場合,クライアント側のリクエストログを活用できるかもしれません。このログファイルは,クライアントからサーバーに送信されたリクエスト情報が記録されています。
SET DATABASE PARAMETER(Client log recording;1)
リクエストログには,さまざまな事例に基づき,パフォーマンスと関係のあることが実証されている情報が記録されています。
v19の時点でリクエストログに含まれているのは下記の情報です。
フィールド名 | 詳細 |
---|---|
sequence_number | オペレーション番号 |
time | タイムスタンプ |
systemID | システム識別子 |
component | モジュール識別子 |
process_info_index | プロセス識別子 |
request | リクエスト識別子 |
bytes_in | 受信バイト数 |
bytes_out | 送信バイト数 |
duration | オペレーション全体に要した時間 ms |
server_duration | サーバーがリクエストの処理に要した時間 μs |
write_duration | クライアントがリクエストの送信に要した時間 μs |
task_kind | プリエンプティブスレッドかどうか |
rtt | ネットワーク通信そのものに要した時間 μs |
-
リクエスト識別子のニーモニックはGitHubで公開されています。v20では
14000
番台にRESTリクエストが追加されました。 -
リクエストログのファイルサイズは,クライアント/サーバー間のネットワークトラフィックが妥当な範囲に収まっているかどうかのバロメーターとみなすことができます。
-
わずかなバイト数のリクエストが大量に送受信されている場合,通信の回数をもっと抑えるよう,プログラムを見直すことが必要かもしれません。
-
リクエストの処理に要した時間と通信そのものに要した時間を突き合わせることにより,通信設備やハードウェアのスペックが充分かどうかを見定めることができます。
-
コオペラティブスレッドのリクエストが相当な割合を占めている場合,プリエンプティブスレッドをもっと活用することでパフォーマンスを向上できる見込みがあります。
リクエストログはサーバー側で記録することもできます。
SET DATABASE PARAMETER(4D Server log recording;1)
v19r5 Hotfix 2では,サーバー側のリクエストログがテーブルに関わるものだった場合,extra
項目にテーブル名が記録されるようになりました。
- | - | - | - | - | - | - | - | - | - | - | - | extra |
---|---|---|---|---|---|---|---|---|---|---|---|---|
60 | - | - | ‘srv4’ | 5 | 71 | 11 | 4 | 1127 | 34 | c | 1000 | |
61 | - | - | ‘INFO’ | 5 | TTF/i | 0 | ||||||
62 | - | - | ‘dbmg’ | 5 | 11041 | 362 | 62 | 1132 | 65 | c | 1000 | Table_1 |
上記の例では,[Table_1]
のトリガがコオペレティブモードで実行されていることが確認できます。
リクエストログは,クライアント/サーバーのネットワーク通信に焦点をあてたログファイルです。4Dには,他にもさまざまなデバッグツールが用意されています。