読者です 読者をやめる 読者になる 読者になる

きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

Strutsのバージョンアップでの性能問題

金曜日の夕方に呼ばれて話を聞いて、
打ち合わせ後に電話するも職場には誰もいなくて土日対応もせず、
先方はかなり忙しくレスポンスも悪く、
知り得ている情報からの解析も頓挫。


たかが1秒未満の話でもなんとかせねばならないのが、
システムエンジニアの悲しい運命。
気持ちが乗らないなー。
でも、問題が起こるとウキウキするのもエンジニアの特性。


Java1.3時代の代物を、
Java5.0に乗せ替えつつ、
APサーバも変わり、
Struts1.0.2からStruts1.2.9に上がる。


そこで起きた性能問題らしい。


ActionServlet#processPopulateだったものが、
RequestProcessor#processPopulateになって極端に遅くなったんだとか。


1.0.2にはDynaActionFormがないので、
リフレくしょんぼりな懸念は薄い。
でも、項目数が多いと極端に遅いらしい。
一体何が起きてるんだろう?


おいらはSpring世代なんで、Strutsは詳しくない。
Java1.3も経験してない。
Struts1.0.2のソースは、commons-loggingすら使われていない旧石器時代の代物みたいだ。
Struts1.2.9のRequestProcessorをjavapしてみたら、
どうやらこの子もJDK1.1時代に生まれ出でたみたいだ。Java5でリコンパイルして置いた方が良いと思う。


Java5でリコンパイルして、javapで逆アセンブルしたRequestProcessorを、Struts1.2.9のバイナリ配布してるやつのjavap結果と比較してみた。
かなりConstantPoolの構成が違ってる。
まあ、コンパイラが違うからな。
Exceptionの記述位置が違っている。
なんでまたこんなところが違うんだ。。。


ldcの変わりに、ldc_wになったっぽい。
あまり本質的なところじゃないな。
一般的な命令に変更は無いみたいだ。
あとから気づいた、IBMJDKでコンパイルしても意味ないし。


RequestProcessor周りのどこかしらを、
旧ActionServletの内容みたいに書き換えると、
従来の性能になるらしい。
この点がかなり気になる。
果たして本当にその処理内容が性能に影響しているのだろうか?


処理を書き換えるのではなく、
Struts1.2.9をJDK5でリコンパイルすれば、
ひょっとして解消されるのではないか?


Struts1.2.9のマニフェストファイルをみると、
それはSunのJDK1.3でコンパイルされてるようだ。


僕の懸念はなんか閃きでしかないが、
なんか勝算がありそうな気がする。


Struts1.2.9をJDK5でリコンパイルするか、
もしくは修正を加えたものをJDK1.3でコンパイルして、
性能への影響を調べて見て、
少しでも切り分けを試みたい。


Strutsのコードは、Multipart対応の修正は多いが、
項目数に比例するような箇所は、
基本的にはBeanUtilsなので、
Strutsのソースを多少書き換えても早くなるとは思えません。


さーて、1日悩んでこんな事しか思い付かなかったが、
きっもなるようになるさ。