« うーん、失敗の香りが…… | トップページ | パフォーマンスに鈍感な作り方 »

2005.10.30

フレームワークの落とし穴

ソースはすべてフルスクラッチ、といった寝言を言う気はないのだが、少し考えさせられた事例。
今月の日経システム構築でとりあげられていたのと殆ど同じ事例が身近にあり、割合普遍的な問題なのだなあ、ということを痛感したのだが、フレームワークが存在することでプログラマは様々な環境のディープな構造を意識することなくコーディングを行うことができる。
これはシステム構築の生産性を考えるときに、大いにプラスなのであるが同時にそのアーキテクトのもつ様々な問題点などを意識しないで作成されることにより、時としてとんでもないものができあがってしまう危険性をはらんでいる。
もちろんこれはフレームワーク単体の問題ではないのであるが、「フレームワーク使ってなければ気付いたろうに」ということになることもある。

3階層型ウェブシステムでWEB UI上は複数行を同時にエントリーができるものがあったとする。
一般的な期待としては、1回のsubmitですべての処理を行い結果を返してもらうことになるだろう。
こうした処理でえらく遅いものがあり、調べ進めて見てびっくり。
1行ごとにSQLを発行し、個別のリターンを待っていたという。
しかも、1行ごとにcommitすることができない性格のトランザクションであるため全行成功でもって初めてcommitできる性質の処理である。
であるからユーザーからみると行数が多くなるほど幾何級数的に処理が遅くなるという大変よろしくない状態であった。
なぜこんなことになってしまったんか、と考えてみると使用しているメソッドが1行ごとの処理を想定したものであった。元々1処理で大量の行数が発生する処理をこのフレームワークは想定しておらず、用意されているメソッド等を利用する限りでは、どうあがいてもパフォーマンスが出ない構造になっていたのだった。

実装に便利なようにつくられている機能を利用したことで、カットオーバー後にパフォーマンス上の問題を大きくかかえ、対応工数がかさんでしまい結果として非常に不満足なシステムとなってしまった。
現在もパフォーマンス改善をへいこらやっている真っ最中である(^^;
実装者側にとって、様々な処理がブラックボックス化されていることは本来メリットであるはずなのだが、こうしたケースのときにはブラックボックスであるがゆえの難しさをかかえてしまうのだなあ、と痛感した一件である。

|

« うーん、失敗の香りが…… | トップページ | パフォーマンスに鈍感な作り方 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/6763425

この記事へのトラックバック一覧です: フレームワークの落とし穴:

« うーん、失敗の香りが…… | トップページ | パフォーマンスに鈍感な作り方 »