Performance 測定 は NRPC Trace を活用 -3-

＜話題の履歴＞

Performance 測定 は NRPC Trace を活用 -2-

Performance 測定 は NRPC Trace を活用 -1-

前回は、Discussion TemplateのDBを例に実際のNRPC Traceの見方を紹介しました。

今回は、このNRPC Traceを活用して、Performance Tuningにどのように活かしていくのかを見ていきましょう。

まず、NRPC Traceを取得したら、情報を整理することが重要です。

NRPC Traceは以前紹介しましたように、以下のフォーマットになっています。

(Repl_ID-NoteID): Time ms, [Upload_Bytes+Download_Bytes=Total_Bytes]

例えば以下のように整理してみましょう。

NRPCトレースの整理フォーマット

		測定環境 #1
NRPC Cmd	処理 内容	処理 時間	送信 バイト	受信 バイト
…..	……	……	…….	……
…..	……	……	…….	……
NRPC 合計		(A)
実測		(B)
差異		(B)-(A)

NRPC Traceは分析のために、ServerのLocal Client上、社内のLocal Area Network上、PHSなどのMobile Device経由など複数のDataを取ることで、Networkの影響を見ることができます。

また、測定は同じ時間帯で行い、取得したDataにServerの負荷状態ができる限り影響しないように考慮してください。

では、このNRPC Traceを整理した情報からPerformance解析を行ってみます。

(1)受信バイト数

　
　まず、設計要素を取得しているOpen_Noteに着目します。
　

その受信バイト数の大きな物を見つけます。

設計要素のサイズが大きくなっているために受信バイト数も大きくなるわけですから、取得しているNoteIDから設計要素を特定して調査してください(Notes R5以下では、NoteIDがNRPC Traceに記録されませんので、Notes 6以降でNRPC Traceを取得することをお勧めします)。

設計要素の中をみて、無駄な大きなImageが貼られていないか、Field Exit Event が書かれていないかなどを調査し、不要な物は削減してください。

　
(2)設計要素の取得回数
　
　次に、Open_Noteの回数に着目します。

一つのオペレーション(フォームやフレームを開く)で多数のOpen_Noteが発行されていないかをチェックするのです。

多数発行されている場合はフレームが複雑な構造になっていないか，フォームでサブフォームや共有フィールド，共有アクションなどの共有設計要素が多用されていないかのチェックを行います。

多段階設計 や共有設計要素 のTipsで述べましたが、これによって重くなっているようなら設計を改善してください。

　
(3)ビューからのデータ取得回数

　
　次は、Open_Collection，Find_By_Keyに着目します。

一つのOpen_Collectionで複数のFind_By_Keyが発行されていないかをチェックします。

このような状況にある場合は、一つのビューから複数の列を取得している場合であり、@DBLookupや@DBColumnが多用されていることが考えられます。

これも、以前紹介したTips に書きましたが、一つの要求にまとめ、Client側で複数値をばらして利用することでPerformance向上が図れるのです。

　
(4)ビューの内容の取得

　
　次は、Read_Entriesに着目してみます。

ビューの表示内容の取得に異常に時間がかかっていないかをチェックするのです。

処理時間が長い場合は、参照しているビューが大きすぎる場合があります。

以前、Tips に記載しましたが、参照Viewは小さいほどPerformanceはよくなるのです。

(5)ネットワーク環境の違いによる差異

　
　今度は、ネットワーク環境の違いによる差異を見てみましょう。

これを見るためにも、LAN上や、Networkの速度が無視できるServer Local上のNotes Client、PHSなどのMobile Device経由での取得が重要なのです。

特に受信バイトは同じでNRPC処理時間が長い場合、想定されるネットワーク速度で受信時間を算出し、受信時間以外の処理時間が異なるネットワーク環境でもほぼ同じであれば、受信バイトを減らすかネットワークを増強することを考える必要があるのです。

　
(6)PCクライアント環境の違いによる差異

　
　PCクライアント環境による違いを見ることも重要です。

NRPCで設計などを取得した時間にはLocalのCacheに書き込む時間も含まれています。

そういう意味では、異なるNetwork環境でNRPCを取得する場合は同じPCでの取得をお勧めします。

また、同じNetwork環境で異なるSpecのPCでのNRPC Traceの比較も非常に役に立ちます。

NRPCの処理時間は、想定されるネットワーク処理時間を差し引くと、NRPC処理のクライアントPC依存部分となります。

また、UIでの実測時間とNRPC処理の合計の差異[(B)-(A)]はPC側の処理そのものの時間となります。

これらを短縮するためには、クライアントの増強または設計の単純化が必要になるのです。

また、アプリケーションに必要なクライアントのスペックを決定する際の参考とすることができるのです。

どうでしょう?

このように見ていくと、NRPC Traceにより、Performance Tuningのヒントが数多く得られることがお分かりいただけたのではないでしょうか?

DBの活用を促進するにはPerformanceのよいDBでなくては、使ってくれる人は少なくなります。

みなさんも、自社のDBで遅いと言われているものを、NRPC Traceを使って分析してみてください。

きっと、改善策が見つかることでしょう。

＜続く＞