■ [Misc] 某開発会社

サーバのスペックが低いんじゃボケーッ！ただでもっといいマシン持ってこーいっ！

とクライアント（アプリを開発してるのは別の会社）に言われたのですが、そんなわけないだろうと、こちらもその上に載っているアプリ(Weblogic + Oracle上で動くWWWアプリ)を調べさせてもらいました。

そしたら、なんと、１つのHTML（表）を生成するためにDBに（計算上）6,000 + 12,000 + 12,000回のアクセスしている画面がありました....。若干複雑な画面ではあるのですがなぜそこまで...。

WHERE句とかの存在を知らないんじゃないかとマジで疑ってしまいました。

■ よくよく聞くとそのうち12,000回のアクセスは不要だそうです...。え？

■ この画面ではないのですがソースも少し読みました。SQLは何かのツールで自動生成したらしくA4で１ページ以上あったりしてホントに必要な条件だけなの？と疑問に思ってしまいます。もちろん、IS NULLとかの遅くなりげな構文とかをふんだんに使っています。

■ ループで毎回DBに問い合わせをしているのはもちろんですが、StringBufferも知らないみたいです。惜しげもなくループの中でStringを使いまくりです。おかげで一時的とはいえ大量なメモリがおもしろいように消費されていきます。

PreparedStatementなんて論外です。そんなの彼らにはムズカシ過ぎです。

SQLの動的部分はもちろん文字列結合です。HTMLだけじゃないんです。文字列のエスケープだってループの中でやっちゃいます。6,000件の中から必要なキーを取得して次のSQLを生成しているのでそれもやむを得ません。

■ 負荷試験と称し、20同時アクセスさせたらDBサーバが死にました。といってもクラスタが切り替わっただけなのですが、それもこれもDBのCPU使用率がしばらく100%に張り付いた状態になり、その結果、ヘルスチェック機能がレスポンス無しと判断しクラスタを切り替えたのです。DBサーバとしては正常動作です。でもクライアントはそれをDBサーバの所為にするんです。

＃もちろんサーバのスペックをあげれば症状は減るかもしれませんが...。

そんなわけで、我々はこの開発会社の作るアプリをDBへのDDOSアプリと名付けることにしました。でも、フロントエンドのサーバもかなりの高負荷になるのでトロイの木馬とした方が良いかもしれません。実際トロイし＜オヤヂギャグ。試験したのが深夜（サービスインしたサーバ上）なのでそんなオヤヂギャグでも大盛り上がりです。

■ とりあえず、Stringで結合しているものをStringBufferに置き換えただけで数分の一の処理時間になりました。実際に置き換えたモノで実演したところ、さすがのクライアントも納得していただけたようです。

たぶん、12,000件の余分なDBアクセスを除けばもっと早くなると思います。

■ あ、ちなみに私はエンジニアではないので、上記解析およびレポートは弊社のエンジニア数名に対応してもらいました。あるエンジニアはソースを見た瞬間に頭痛がしたそうです。温厚な彼が言うのですから、私が見たらキレてるに違いありません。

■ もちろん、メモリ・CPU使用率・ソースコードの解析結果・改善点の指摘等の詳細なレポート付きです .... ここまでやって無料。うがーっ！！！

■ そんなわけで感想

最近のMS Windowsサーバってある意味スゴイね。よく頑張った。UNIXだったらもう少しがんばったかもしれないけど、そこまでするアプリでもないしね。

それにしてもアプリベンダもハードのスペックやOSの所為にしないで少しは反省して欲しい。

StringBufferとかPreparedStatementの件はオレも昔やらかしたことがあるからあまり人のこと言えないんだけどさ。150秒かかって表示される画面なんて誰も使えんよ。

ついでに、ここまでしないと納得してくれないクライアントって...とっとと退散したい。

■ ちなみにここで書いた内容は若干フィクションが入ってます。と言っておきます。

■ 次の日

別のアプリ（デーモン）でSocketExceptionが出ました。クライアントからアクセスされた後、reset by peerなんたらと出てその後の接続要求を受けつけなくなります。

アプリベンダ曰く、ソースに悪そうなところが見あたらないと言うことなのでネットワークのパケットをキャプチャして欲しい、というのです。

いろいろ言いたいことはあるのですがその部分のソースを見たわけではないのであまり疑うようなことも言えません。

そんなわけでさっそくパケットキャプチャを仕掛けました。今のところその症状は１回しか発生していないのでいつまでパケットフィルタを動かしっぱなしにするのかはわかりません。日々蓄積したデータはHDDを圧迫しないように手作業で破棄する予定です。

■ はー、オレは一体何をやってるんだ...。