ZOKU..日日之事柄

MacromediaのサイトからFlex1.5のチューニングポイントを抜粋。 - flex-config.xml内のキャッシュサイズは十分確保しているか？ → flex-config/cache/content-sizeの値を確認。デフォルト値500が指定されていれば問題ないはず。 - flex-config.xml内でproduction-modeをtrueにしているか？ → flex-config/production-modeの値を確認 ただし，アプリケーション更新時にアプリケーションかサーバの再起動が必要になることに留意する。 - flex-config.xml内で最適化を有効にしているか？ → flex-config/compiler/optimiseの値を確認 ただし，アプリケーション内のtrace文が無効になることに留意する。 - 通信プロトコルにAMFを使用しているか？ → MXMLのmx:RemoteObjectタグを利用していれば自動的にAMFが利用されているはずなのでOK - RemoteObjectのtype属性は"stateless-class"か？ → MXMLのmx:RemoteObjectタグを確認。未指定の場合はデフォルト値"stateless-class"が使用されるのでOK。 - RemoteObjectのconcurrency属性は"multiple"か？ → MXMLのmx:RemoteObjectタグを確認。未指定の場合はデフォルト値"multiple"が使用されるのでOK。

カスタムタグを利用してjsp内にmxmlを記述することが出来ます。が、落とし穴がありました。 どうやらリクエスト毎にmxmlのコンパイルが走るらしいです。 しかもその度、mxmlファイルにロックがかかる見たいです。 それがボトルネックになっていたみたい。 先ずは何かしら逃げ道がないかどうかを調べましょう。 mxmlcとか。 無ければhtml化を考えましょう。 てか、そんなイケテナイ実装アリデスカ？ そのものズバリ。 http://www.adobe.com/jp/support/flex/ts/documents/1332aa75.htm flex1.5のバグだそうです。 あぁ。

RemoteObjectに性能問題がありそう。 5000件のデータを処理するのに1分程度かかってます。 # サーバ側の処理は1秒以下。 「Object.registerClass()」を使うと、ActionScriptとJavaの間で明示的に関連付けが出来るそうです。 その結果、ActionScript(RemoteObject?)が一生懸命探さなくなるので早くなるそうな。 んで、実際やってみました。 実行速度、約2倍。 ぶっちゃけ、2分が1分。 でも、遅い。 それ以上早くするには通信するデータサイズを小さくするしかないそうな。 ていうか、8Mの通信とかありえん。 どんな設計思想だ？これ。

■ 使用するツール群(client側にインストールする) ・java1.4.X → 下記ツール群を動かす為に必要なプラットフォーム ・HPjtune → javaのGCの動作を見るためのツール ・HPjmeter → optimiser ・samurai → スレッドダンプを見るためのツール http://yusuke.homeip.net/samurai/samurai.jnlp http://yusuke.homeip.net/samurai/ ■ HPjtuneの使い方。 1. Server側でGCログを出力するようにする -Xverbosegc[:help]|[0|1][:file=[stdout|stderr| ]] 2. GCログをHPjtuneに読み込ませる [check point] ・Summary パネルにデータが表示されるのでチェックします。 全GC に使われた時間の割合（バー表示） フルGC に使われた時間の割合（バー表示） フルGC と全GC の比較（パイチャート表示） ・Heap usage パネルを選択すると、表示内容から以下のことがわかります。 　ヒープの利用が単調増加し、ヒープが一杯状態に向っている。 　実行中に起こっているGC のタイプを見ると、前半は、Scavenge 　GC とSystem.gc だが、後半でOld 領域が一杯になったことが原因で 　Full GC が起きている。 ・Duration パネルを選択すると、表示内容から以下のことがわかります。 　後半のある点から、GC 時間が急に増加している。 　Full GC にかかる時間はScavenge GC にかかる時間に比べかなり長い。 ・Cumlative パネルを選択すると、表示内容から以下のことがわかります。 　作業量をあらわすObject Allocation がGC に時間がかかりはじめると、その傾きが減少している。 ■ HPjmeterの使い方。 1. Server側でプロファイリングログを出力するようにする -Xeprof[:help]|[0|1][:file=[stdout|stderr| ]] 2. プロファイリングログをHPjmeterに読み込ませる。 ■ samuraiの使い方 1. スレッドダンプを取得する。 　　hpuxについているシェルを実行

[前提条件] Weblogicの機能で、サーブレット単位で実行キュー(ThreadPoolと認識しております)を分ける事が出来ます。 [問題点] 今回の画面系の機能では、業務上、遅い処理と早い処理があります。 遅い処理例: ・巨大ファイルのアップロード/ダウンロード機能 ・数千件データの一括確定処理 現状の設定では遅い処理も早い処理もWeblogic上の同じ実行キューにて処理されてしまう為、遅い処理にて実行スレッドを全て占有されてしまう可能性がございます。 # Thread Poolの占有が問題となっております。 [解決案] 遅い処理用の実効キューと早い処理用の実行キューとに分割する事により、遅い処理によりスレッドを全て占有されてしまっても、早い処理に影響を与えてないようにしてはどうでしょうか。 ■ 構成 FLEXを採用し、RemoteObjectを採用している為、以下の2つのパーツに分かれていると認識しております。 # Flashのダウンロードは省きました。 JSPへとリクエストを発行し、HTMLを取得する。主に画面表示に使用しています。 flashからRemoteObjectを使用してリクエストを発行する。主にFlash上でのイベント処理に使用しています。 1)に関しての考察 JSP毎にweb.xmlにサーブレットの記述を行えば実行キューの分割が可能です。web.xmlだけの変更で対応可能ですが、本リクエストの処理は非常に軽い為、分割する意味は無いと考えています。 2)に関しての考察 「AMFGatewayServlet」を使用している為、RemoteObject単位での実行キューの分割を行う為にはWebアプリケーション単位での分割(warの分割)が必要と考えています。 ■ 分割方法 上記理由より、実行キューの分割をする為にはwar分割するのが良いかと考えます。 # web.xmlだけの変更でどうにかなるのであれば問題ないのですが、何か良い方法をご存知の方がいらっしゃれば、ご連絡下さい。 分割指針としては、機能群単位での分割が良いかと思います。 ■ weblogic側設定方法 0. 参考URL http://jp.bea.com/e-docs/wls/docs70/perform/A