akky’s log

異様に遅い処理があるのでその原因を突き止めるたい。

xdebugのインストール方法については過去のエントリを参照。

/usr/local/lib/php.ini へ追加

xdebug.profiler_enable = 1
xdebug.profiler_output_name = crc32
xdebug.profiler_output_dir = "/tmp/xdebug"

/tmp/xdebugの権限を777に変更してapacheを再起動

実行

ブラウザから遅い画面へのリクエスト

プロファイルのファイルを取得

/tmp/xdebug/crc32.xxx が出来上がっているのでftpで持ってくる。

結果表示

WinCacheGrindを取得してインストール。起動させたら、プロファイラが出力したファイルを読ませる。

参考にさせていただいた

http://php.y-110.net/wiki/index.php?%A5%D7%A5%ED%A5%D5%A5%A1%A5%A4%A5%EA%A5%F3%A5%B0%A1%A7xdebug%20%2B%20WinCacheGrind

昨日のエントリとも関連して
これまで、Webのサンプルを多く見つけられるver.1.0時代のDAO方式を使っていたけど、コネクション周りの挙動がすっきりしないので、iBATISのサイトにあるドキュメントを読んでいくと Ver2.0から使われるSqlMapClientの方素直に作れる予感。

半日かけてコーディング変更した甲斐はあり思うように動作している。でも、個人的にはDAO方式のコーディングが好みかな。実行するSQLをメソッド名で指定することで、コンパイル時にコーディングミスを発見できる嬉しさがある。パラメータに文字列として渡すのは実行してみないとミスに気づかないんだよね・・・。あっ。JUnitでしっかりテストすればいいんだけど、つい、億劫になってかかないんだよね。

JUnit。しっかり整備すれば強力なアイテムではあるけれども・・・・

ibatisを使っていると、DB（今回はMySQL)への接続が増える一方で減る気配がない。
# mysqladmin process
としてみるとアイドルな接続がモリモリ。

ibatisではjava.sql.Connection#Close()を明示的に実行する必要がないのは嬉しいけどDBへの接続が溜まり過ぎるのは困る。試行錯誤している中で手動でGCを行なうとMySQLへのコネクションが減った。finalyzeのタイミングか・・・。まあ、明示的にDBとの接続をcloseしないのであれば、DBから切断するタイミングはfinalyzeしかないよな。

それともう一つの理由。com.ibatis.dao.client#startTransaction()を行なっていないと、DAOからSQLを実行する都度、トランザクションを開始してSQLの実行完了後にcommitしている（ibatisが）。

当初はstartTransaction()の事には気づかなかったので、jvmのGC関連のパラメータを調整しても多少の延命はできても、JVMでのOut of memoryかDBでのtoo many connectionがおきてしまうので問題を解決できていない。
ふと、思い立って機能の単位にcom.ibatis.dao.client#startTransaction()とcom.ibatis.dao.client#endTransaction()を入れたことにより、ヒープの使用量とDBへの接続数が安定するようになった。GC関連のパラメータ調整よりもこちらの変更が的確だとおもうので、全体の完成度が上がってきた時点でもう一度GC関連のパラメータを調整する予定。