プロファイリング再び失敗

jMechanicは使い物にならない、という認識でOK？

eclipse profilerがダメだったので、今度はjMechanicを使ってやろうと思い立った。

eclipse profilerはネイティブな上に独自のプロファイラを使うといった、ちょっと特別なことをしているので、JCE周りでいろいろトラブルが起きた。しかし、jMechanicはPure Javaで、かつJVMが最初から実装しているhprofを使ったプロファイルを行う。つまり、やってることが普通である。これなら期待できそうではないか。

そういうわけで、マニュアルを斜め読みしつつ（ありがたいことにTomcatのプロファイル方法、といった今の俺にピッタリのドキュメントがあった！）、セットアップして、実行。・・・Address already in use、だとぉ？どうやら他のアプリケーションが使っているポート番号を重複して使おうとしているらしい。ポート番号指定する場所なんて一箇所しかなく、nmapで使っていないポートを確認した上で値設定してあるから、そんなことになるはずが無い。

しかし、どうあがいてもこのエラーが取れない。エラーログにもポート番号まで表示されないし、localhostへの接続なので、snifferでパケットを拾って確認することもできない。

仕方が無いのでRemote Profileに挑戦。しかし、Remote VMに接続拒否された、といった意味のエラーが出てくる。なにかデータのやり取りをしているのは見ていてわかるので、プロトコルが合ってないとか、データがぶっ壊れているとか、そういう原因しか思いつかない。似たようなことをやってるリモートデバッグを試してみたが、これはうまくいく。JVMが出たばかりの1.4.2_09なのが問題なのか？と1.4.2_04に戻しても現象変わらず。

散々イライラしながら格闘したが、結局断念。とにかくうまくいかない。俺をここまで苛立たせるのはデータベースぐらいだと思っていたが、世の中は広い。

実は、hprofの出力結果+HPjmeterとログ出力を眺めていて、ある程度ボトルネックになっている箇所の見当はついているので、このままプロファイラを使わずに地味に解析を進めることもできる。しかし、こういうときは常に先を見なければならない。今はそれで良いかもしれないが、近い将来またパフォーマンスがらみの問題に直面することは十分ありえるし、その問題が今回のように地道な努力で解決できるような単純なものであるとは限らない。プロファイラはどうしても使いこなせる必要がある。

そういうわけで、次はJProbe Profiler Freewareに挑戦しようかと思ったのだが、いろいろ面倒が多そうな感じ・・・。プロファイラなる存在を一気に嫌いになりそうである。