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になったっぽい。
あまり本質的なところじゃないな。
一般的な命令に変更は無いみたいだ。
あとから気づいた、IBMのJDKでコンパイルしても意味ないし。

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

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

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

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

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

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

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