MDBの性能を処理対象データに基づいて計測する方法の考察

z/OSではRMFを使って性能測定をするのが普通のようで、おそらくどこでもやっているだろう。

どれだけ性能分析をカテゴライズ出来るかに興味がある。
性能分析といっても色々あるからな・・・、
ここではアプリケーションの立場からの分析を補助出来るか否かに焦点をあてている。
全体の中で見れば、あまり役に立つ情報ではないだろう。

自分が考えてる方法は２つある。実験はしてない。
１つはwlm_classification_fileで細かく指定する方法。
１つはSMF120-9を使う方法。

まずは１つ目の方法を考えてみる。
基本的にwlm_classification_fileは使った方がいい。
それは少なくとも、データに応じた分析をする依然に、MDBレベルの分析はこれで出来るからだ。
それにF server,DISPLAY,WORK,CLINFOをした際に、Descriptionを出すためにはこのファイルが必要だ。

MDBと言ってもClassificationは3つ存在する。(正確には4つかも？PLAN BはInternalだから)
今回はListenerPortの場合を考える。
InboundClassificationというエレメント。
まず、ここでデフォルトトランザクションクラスをかける。
次に、endpointエレメントがあり、ここでリスナーポート名とdefaultclassificationがかける。
忘れちゃいけないのが、ここでdescriptionも書くことだ。
さて、データに応じたclassificationを行うには、
classificationentryエレメントで、セレクターを書き、トランザクションクラスを割り当てることになる。
（ここでもDescriptionは書いた方がいい）
その際に注意が必要なのは、ejb-jar.xmlにもmessage-selectorが必要ということだろう。
これは厄介だ。
同一のリスナーポートでデータに応じてトランザクションクラスを分けたいわけだが、
ejb-jar.xmlに手が入るってことは、1つのリスナーポートに対して、複数のMDBを設定することになる。
クラスは同じなんだが、名前を変えて作らないといけない気がする。
出来るよな？出来たとしても少し気持ち悪いよな。
これをやるということは、CR部分の挙動が大幅に変わる。
メッセージ・セレクターはMQからBROWSEするときに使うものなので、
MQにアクセスする頻度がけっこう増えることになる。（コンシューマーの種類が増える）
ただし、BROWSE部分は、エンクレーブに含まれない点はここに書いておこう。
CRのコストは目をつぶってSR上のコストを見る分にはこれでも構わないだろう。

WLMポリシーの方でも、トランザクションクラスに応じた定義をする必要もある。
サービスクラスは増やさない。レポートクラスだけを増やす感じ。
サービスクラスの種類は多くても２０から３０くらいじゃないといけない。
ここまで書いてきた方法で、メッセージ・セレクターで分類出来るデータに応じてレポートクラスを分けることは可能ではないかと思う。

若干気になる点もある。
WebSphere Application Server and the z/OS Workload Manager
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101740
MQ Queueの性質によって、PLAN AになるかPLAN Bになるかという点。
TOPICがPLAN Bになるのは間違いないんだが、PLAN Aの説明が気になる。
Non-PersistentのQueueでもPLAN Aになると思うんだが・・・。自分の英文解釈間違いかな？

もう一方のSMF120-9での方法を考えてみる。
この方法はアプリケーションを変える必要が出てくる。
考えてることは、SMF120-9のUSER DATA領域の使用だ。

実装の参考となるのはこれ。名前が紛らわしいけど。
Adding a servlet filter to all web applications in a server without application change
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101859

簡単に言うと、SmfEventInfrastructureをSmfEventInfrastructure.SEI_LOCでルックアップして、
SMF120-9を収集しているなら、データの長さに気をつけつつ、USER_DATA領域にデータを入れる。
最大で5つのユーザーデータを追加出来る。各データは2Kを超えてはいけない。
まあ、2Kを超えるようなデータを入れようとは思わないけど。
トランザクション・クラスでレポートクラスを分ける方法の場合、
セレクターで取れる情報でしか分類は出来ないがこちらの方法ではそれ以外のデータも分析に使うことが可能だ。
「入力」だけでなく「出力」に関するデータも扱える点が大きく違う。
しかし、SMFレコードを解釈するコードを書かないといけない点もつきまとう。
何を5つのデータにするのかという点の整理が必要だったり、考えたり作ったりする部分が多い。
RMFレポートとは違うので、他の製品の性能と混ぜて扱うのには向かない気がする。
ユーザーデータはどうも即座に書かれるわけではないようだ。おそらくCRが最後に書き込む。

どちらもJavaプロファイラーみたいなことが出来るわけではないから、それはそれでやるべきだ。
継続的に性能情報を蓄積していくなら、上記のような手法でデータを集めて傾向を把握することは意味があるだろう。
実際に性能問題にぶち当たった場合はとっととJavaプロファイラーをかけたほうがいい。
当然だけど、Javaではなく、DBだったりOSとのやり取りの問題だとプロファイラーは意味ない。