About measuring message processing performance
メッセージ処理に関する箇所の時間やサイズ等のパフォーマンスを測定するという話。
- パフォーマンス測定機能はデフォルトでは disabled。
- パフォーマンス測定機能を enable にすると、メッセージサイズ、サーバ処理時間、ネットワーク通信時間を測定可能。メッセージをサーバにプッシュしたクライアントや、サーバからプッシュされたメッセージを受信したクライアントや、プッシュしたメッセージの応答を受けたクライアントで測定可能。
- 部分的な情報はサーバでも確認可能。
- BlazeDS のプロキシを使わないで外部サーバとやり取りする場合には、パフォーマンス測定を利用できない。
- メッセージ処理のメトリクスは MessagePerformanceUtils で定義される。Producer が ack を受けたときや Consumer がメッセージを受けたときに、このクラスのインスタンスにデータが格納され、そのプロパティを確認することによりパフォーマンスを確認できる。
- メッセージを受け取った場合に、メッセージ送信元を特定する情報を得ることはできないらしい。
- ポーリングではない本当のリアルタイムメッセージでは、networkRTT、serverPollDelay、totalTime は測定できないので 0 が入る。
- 以下、一部のメッセージ処理メトリクスの説明
- clientReceiveTime : クライアントが応答メッセージを受け取った時間。UNIX時刻のミリ秒。
- messageSize :クライアントのオリジナルメッセージのバイト数で、サーバの endpoint でデシリアライズされたサイズ。
- networkRTT : totalTime - serverProcessingTime。メッセージの送信から受信までの時間からサーバ処理時間を抜いたものなので、純粋にネットワーク通信の時間となる。ストリーミングの場合は無意味なので0が入る。
- originatingMessageSentTime : クライアントがメッセージを投げた時間。ackは対象外。
- originatingMessageSize : 元のメッセージサイズ。ackの場合は対象外。
- pushedMessageFlag : ポーリングではない真のプッシュの場合には true になる。ackは対象外。
- pushOneWayTime : プッシュされたメッセージの送信から受信までの時間。クライアントとサーバの時計が合っていることが前提。ackは対象外。
- responseMessageSize : 応答メッセージのサイズ。サーバ側の endpoint でシリアライズしたときのサイズ。
- totalPushTime では Producer と Consumer の時計が合っていなければ値の信頼性が損なわれる。
- pushOneWayTime ではサーバと Consumer の時計が合っていなければ値の信頼性が損なわれる。
- タイミング情報だけを収集するテストと、サイズ情報を収集するテストは別で行い、最後のそれらをあわせたテストをすべき。タイミング収集をするときにサイズ情報を収集すると、誤差が大きくなる。
Measuring message processing performance
- 機能の enabled / disabled はチャネル定義の record-message-times と record-message-sizes 要素で設定する。
- new MessagePerformanceUtils(event.message) みたいな感じでOK。
- prettyPrint() メソッドで情報の文字列化をお手軽に行える。
TODO：実際にやってみたけど、totalTime とか networkRTT がマイナスの巨大な値になる。なぜに？要調査。
0 件のコメント:
コメントを投稿