ZOKU..日日之事柄

いつもいつも覚えられないので、メモ。 ■参考文献 J2EEパフォーマンスチューニング徹底解説―見えないところを手抜きしないWebシステム実現のために (アドバンストサーバサイドプログラミング) posted with amazlet at 10.02.12 日立ソフトウェアエンジニアリングインターネットビジネス部 紀平 篤志 河村 嘉之 北林 拓丈 阿川 典夫 技術評論社 売り上げランキング: 489083 おすすめ度の平均: 現実どおりにはいかないけど 実用的なパフォーマンスの本 この本は使える Amazon.co.jp で詳細を見る ■スループットの定義 　単位時間（秒）当たりにシステムが実行できる処理数 ■平均スループットの計算式 　A=（α×β×γ）÷（24×60×60）÷ω 　α：想定ユーザ数 　β：利用率（１０％程度） 　γ：ユーザ毎のアクセスページ（１０ページ程度） 　ω：偏り率（一日の内のアクセスが集中する時間帯：３５％程度） ■目標スループットの計算式 　B=A×ピーク時倍率   ■サーバ台数の算出方法 　B÷（１台当りのスループット）＋１台（冗長化） ■チューニング時に取得する値（AP、DBサーバ） 　・スレッド数（パラメータ） 　・JDBCコネクション数（パラメータ） 　・スループット 　※注意：DBサーバは一台の為、最大コネクション数は全ＡＰサーバの合計値となるようにする 　※注意：ＡＰサーバのＣＰＵ使用率は６０％程度を目標とする 　※注意：ＤＢサーバは７０％程度にする？   こんな感じか？

「ログにユーザID出してよ」という要望に比較的簡単に答える方法について説明。 久々の技術ネタ。 ■前提条件 　・J2EE1.3以上（Filterが使える事） 　　Tomcat4.2以上なら対応していたハズ。 　・Log4jとかLoggerを元々使っている事。 ■説明 【製造物】 　・ThreadMappingSingletonClass 　・ThreadRegistFilterClass 　・自前LoggerClass 　・web.xml（編集するのさ） 【クラス概要】 　■ThreadMappingSingletonClass 　　・概要 　　　スレッドIDとユーザIDを保持するシングルトンクラス 　　・フィールド 　　　・Map：スレッドIDとユーザIDを保持するマップ 　　・機能 　　　・登録 　　　　　スレッドIDとユーザIDを引数とし、Mapに登録する。 　　　・削除 　　　　　スレッドIDを引数とし、Mapから削除する。 　■ThreadRegistFilterClass 　　・概要 　　　RequestをFilterし、ThreadMappingSingletonClassに登録、削除をする。 　　　Filterをimplimentsする事。 　　・機能 　　　SessionなりRemoteUserなりでユーザIDを取得し、ThreadMappingSingletonClassに登録する。 　　　因みに、Finallyで削除するのが良いと思う。 　■自前LoggerClass 　　・概要 　　　ThreadMappingSingletonClassからスレッドIDをキーにしてユーザIDを取得する。 　　　ログ出力メッセージの先頭にユーザIDを出力する。 　　　LoggerをExtendsなりimplimentsする事。 　　・機能 　　　それぞれのメソッドをオーバーライドなり何なりして、適切にメッセージが出力出来るようにして下さい。 本当はシーケンス図があれば分かりやすいんだろうけど、めんどいので割愛。 分かって。

※気に入ったらアフェリエイトのクリックをお願い♪ ■Introduction 1. チューニングの目的 2. チューニングポイント 3. まずは何もしないでGCを測定してみよう！ 3.1. Summary 3.1.1. Heap Capacity 3.1.2. GC Activity Summary 3.1.3. Overall Statistics 3.2. Heap usage 3.3. Duration 3.4. User defined 4. アプリケーションに合わせたGCアルゴリズムを選択しよう 4.1. 「-server」オプションを試してみましょう。 4.2. 「-noclassgc」オプションを試してみましょう。 4.3. 「-XX:+UseParNewGC」を試してみましょう。 4.4. 「-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=32」を試してみましょう。 5. Heapの最適値を探しましょう。 5.1. まずは、「-Xmx1024m」を設定してヒープの上限を見極めましょう。 5.2. 次に、ヒープのextensionを抑制してみましょう。 5.3. 「-Xmn32m」を試してみましょう。 5.4. 「-Xms128m -Xmn64m」を試してみましょう。 5.5. 「-Xmx1024m –Xms256m –Xmn128m」を試してみましょう。 6. 最後に 1. チューニングの目的 一般的に、チューニングを行う目的は実行時間を短くすることです。 本ドキュメントでも、実行時間を短くすることを目的にチューニングを行っています。 2. チューニングポイント 本ドキュメントでは、Java VMの起動オプションを変更することにより、実行速度の向上を実現します。 その際に必要なポイントとしては、以下のものがあります。 ・GCアルゴリズムをアプリケーションにあったものにする。 ・GC回数をなるべく減らす。 ・GC時間をなるべく減らす。 3. まずは何もしないでGCを測定してみよう！ JavaVMのパフォーマンスチューニングを行う前に、まずは現在の状態を正確に把握しましょう。そうでないと、チューニングを行った結果、早くなったのか遅

カスタムタグを利用して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

Tomcat4系にて、Tomcat再起動時にSession情報はクリアされているのかと思いきや、実はファイルに保存して再読込していることが分かりました。 アプリケーション再起動時に保存されるセッション状態を記述したファイルがあります。 デフォルトでは workDir/SESSIONS.ser ですが、ここではそのファイル名およびパスを指定する事が出来ます。 Session使っていない場合、無駄なリソースを食っていると言えば食っているのでSessionを削除する方法について調べてみました。 １．Sessionを作らないようにする JSPのディレクティブでsessionを利用するか選択できます。session=falseの設定をしておくと、sessionが作られません。 記述例: <%@ page contentType="text/html; charset=Shift-JIS" session="false" %> また、request.getSession(false)とすることにより、新たにSessionを作らなくなります。 Sessionがない場合、nullが返却されます。 2. 作ったSessionを毎回削除する filter機能を使用して、リクエスト毎にSessionを削除するようにします。 なお、Filterをかませた場合、0.1秒前後遅くなりますので注意して下さい。 サンプルコード： import java.io.IOException; import javax.servlet.Filter; import javax.servlet.FilterChain; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletRequest; import org.apache.log4j.Logger; import org.apache.log4j.Priority; public class

defaultRowPrefetch?のサイズを変更することにより、格段にパフォーマンスが上がるそうです。大量のデータをDBから取得する際に有効と思われます。 以下原文 以下の記述でみごと解決致しました。 java.util.Properties info = new java.util.Properties(); info.put("user", "scott"); info.put("password", "tiger"); info.put("defaultRowPrefetch", "100"); Connection conn=DriverManager.getConnection("jdbc:oracle:thin:@ホスト名:1521:テーブル名", info); プリフェッチのサイズはDefaultで10だそうで、 とりあえず100にしただけで、1万件あたり約3.5分が わずか3秒になってしまいました。 本当にどうもありがとうございました。

Apache2+Tomcat4をmod_jk2で連携させようとがんばりました。 Tomcat4に以下の設定をすると、Tomcatが自動でmod_jk.confを作ってくれます。 <Listener className="org.apache.ajp.tomcat4.config.ApacheConfig" modJk="/Apache2/modules/mod_jk2.so" jkDebug="info" workersConfig="/Apache2/conf/workers2.properties" jkLog="D:/Apache Group/Apache2/logs//mod_jk.log" /> <Listener className="org.apache.ajp.tomcat4.config.ApacheConfig" append="true" /> で、作られたmod_jkには、以下の記述がされております。 <VirtualHost localhost> ServerName localhost JkMount /admin ajp13 JkMount /admin/* ajp13 JkMount /webdav ajp13 JkMount /webdav/* ajp13 JkMount /examples ajp13 JkMount /examples/* ajp13 JkMount /tomcat-docs ajp13 JkMount /tomcat-docs/* ajp13 JkMount /manager ajp13 JkMount /manager/* ajp13 </VirtualHost> この、VirtualHostの設定がされていると、「http://localhost/」で始まらないとJkコネクタが効いてくれないという事が分からず、午前中を潰しました。 ・・・くそぅ。

効率的な開発について考察中。というか、調べ中。 基本的に「後戻り」しない為の布石をどんだけ打てばいいのか？ちゅうことで思案中。 Cはわからんので、取り敢えずJavaで考えて見てます。 http://www.mogusa.com/waterfall2006/ # なんて、間違ってもプロジェクトメンバには教えられません...。 # 本気にされたらどうしよう....。 取り敢えず、OpenSourceの開発方法が有効なのかも、と思い始めた今日この頃。 ■言語の癖 　言語によって、「こんな書き方しちゃいけませんよ」とか「そうコーディングするとパフォーマンス問題が発生しますよ」とか、コンパイルや単体テストじゃ分からない問題点というのがあったりします。 　で、そういう問題が明るみに出るのは大体結合テストとか連動テストとか後のほうの工程だったりします。 　そういう問題を未然に防ぐ為、コード標準とかある訳ですが、あった所で守られているかどうかチェックされなければ意味なかったりします。 　チェックする為に人間使ってソースレビューした日にはもう大変。ソースレビューが好きな人は中々おらんです。 　というわけで、製造中に製造者にチェックしてもらいましょう。ツールを使って。 　ちゃんと守られているかどうかも、一括でチェック出来るので、便利かも。 　[参考] 　http://www-06.ibm.com/jp/developerworks/java/040625/j_j-findbug2.html ■その単体テスト、大丈夫ですか？ 　単体テスト仕様書とかある訳ですが（何故か明るみに出ませんが）、「その単体テスト、本当に網羅されてますか？」なんて分からんのです。 　JavaですとJUnitがあります。ある意味実行出来る単体テスト仕様書。じゃあ、その単体テストは全パターン網羅されてますか？なんて言われても分からんのです。で、結合テストでバグが発見されても「レアケースでした」なんて言ったり言わなかったりします。 　要は、「作ったメソッドが想定しているような動きをしているかどうか」というのがキモなのです。 　で、想定しているテストを行った際に、全てのコードを網羅していますか？というのが一つのチェック基準となるのかな？と考えたりしました。 　という訳で、この辺りもツール化出来てるので、嬉しかったりします