7 6 トレース ハンドラーのガイドラインとパフォーマンス

Visual LANSA

7.6 トレース・ハンドラーのガイドラインとパフォーマンス

RDML コードに埋め込むトレース・ステートメントの数には制限がなく、自身で決定することができます。

ただし、トレース・ステートメントを多く含め過ぎると、生産性が落ち、巨大なトレース・ファイルは分析が難しくなる可能性があります。また別の極端な例として、RDML コードにトレース・コマンドを特別な構造もなく適当に置いた場合も、問題の特定する際に役立たない可能性があります。

まずアプリケーションの分析を行って、主要プログラムや重要なエリアを特定することをお勧めします。これは例えば、レコードを読み込んだ直後やレコード更新前、サブルーチンやメソッドを起動させてデータを操作する時などの他、プログラム実行の前後にトレース・コマンドを追加するのも有効です。

トレースの出力フォーマットを標準化し、その時のデータ値とともに、実行される処理タイプも含めるよう考慮することも大切です。これにより、RDML ソースに慣れ親しんでいなかったとしても、出力の意味が理解しやすくなります。

#Sys_Appln.TraceMessageText("UPDATE Employee &1 Name &2 &3" #Empno #Givename #Surname)
 

このトレース機能は、トレース・コマンドがアプリケーション内に埋め込まれても、パフォーマンスに悪い影響が出ないように設計されています。トレースを開始するトリガー・メカニズムがアクティブでない場合、トレース・ハンドラーはインストールされません。その結果、トレースのメソッドが呼び出されても何も起きません。これは、空のメソッドを呼び出すのと同じで、パフォーマンスへの負荷は取るに足らないものです。簡単なテストの結果では、トレースが非アクティブな状態の場合、100,000 件のトレース・ステートメントが実行時に与える影響は約 0.25 秒ほどでした。トレースがアクティブな状態の場合でも、トレース処理は約 45 秒ほどでした。