アプリ開発でも、よ〜く考えよう。現場から学ぶWebアプリ開発のトラブルハック(12):アプリ開発でも、よ〜く考えよう。(1/2)本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。});“無駄”より“遅い”ものはない今回もパフォーマンスにまつわるトラブルをハックするが、アプリケーションのパフォーマンスチューニングで最も有効な手段は「処理を行わない」ことである。何もしないことに勝る高速化は存在しない。今回のトラブルでは、インスタンスをキャッシュ化して、無駄な処理を行わないことでチューニングを行う手法を紹介する。してチューニングはトレードオフである。そのトレードオフが引き起こす、さらなるトラブルを紹介する。■コンサルティングもトラブルハッカーの仕事とあるプロジェクトから1通のメールが届く。「あるJavaで作成したリッチアプリケーションのパフォーマンスに問題を抱えている。自分たちで考えられ得る対策は講じた。目標のパフォーマンスを達成できない」とのことで、相談に乗ってほしいそうた。いったケースをメールでやりとりしても“らち”が明かないため、早速現場へ急行する。トラブルが発生した場合に何をするべきなのか、が分からないプロジェクトは多い。そんなプロジェクトのコンサルティングを行い、進むべき道を示すのもトラブルハッカーの仕事である。■まさかXMLが早速現場の担当者にヒアリングを行う。今回パフォーマンスが出ていないシステムはJavaリッチアプリケーションであり、サーバとクライアントの間の通信をXMLで行っている(図1)。システム構成また、これまでの調査では、サーバ側の処理はさほど速度が遅くはなく、クライアント側の処理がボトルネックになっているとのことであった。SOAPに代表されるXMLを用いて通信を行うシステムでは、XML操作に関する以下の処理がボトルネックになりやすい。XMLのパースXMLとJavaオブジェクトのマッピングXMLの取り扱いには苦い思い出があるため、真っ先に担当者へ確認をしたがXMLに関しては「すでに以下のようなチューニングを施した」と伝えられた。先入観は判断を鈍らせる先入観を持つと視野が狭くなって、問題の本質を見失ってしまう。冷静になり事態を整理する。GCの頻度はさほど高くない通信が発生する操作を行うとCPU利用率が急上昇する以上から、本連載第1回「Webアプリの問題点を「見える化」する7つ道具」のトラブル切り分けフローに基づき、メソッドプロファイラの導入を決定して、処理時間がかかっているメソッドを特定することにした。kwout■プロファイラは、何でもお見通し早速、フローの手順3「メソッドプロファイリング」に基づき、あるメソッドプロファイラをアプリケーションにアタッチして、どのメソッドがボトルネックなのかを確認した。結果を平均化するため通信を行う操作を10回繰り返したときの結果をプロファイリングした。プロファイリングの結果は図2のとおりである。プロファイリングの結果(一部を再現したものです)(画像をクリックすると拡大します)一見すると、普通のプロファイリング結果であるが、よく見てみると大きな問題に気が付く。「getInitBillingProps」メソッドの呼び出し回数が実行回数の10回と一致しているのだ(図2の赤枠参照)。名前から推測するにアプリケーション初期化のためにプロパティファイルのロードを行い、プロパティの値をインスタンス化しているようである。メソッドの名前どおりの動作を行っているとすれば、アプリケーションの通信の操作を10回繰り返したからといって、「getInitBillingProps」メソッドが10回実行されるのは明らかにおかしいはずである。■「getInitBillingProps」メソッドの挙動を確認まずは、ソースを確認する。プロパティファイルからプロパティの値をオブジェクト化しているだけである。念のため、忙しそうにしている担当者を捕まえて、メソッドの仕様の確認をした。「getInitBillingProps」メソッドはアプリケーションの初期化のためにプロパティの値をインスタンス化するためのメソッドらしい。通信時の挙動すなわち、このアプリケーションは通信を行うごとにプロパティファイルにアクセスしていることになる。つまるところ、完全に無駄な処理を行うのである。これでは、パフォーマンスが出るはずもない。読者の皆さんも考えてみてほしい。次ページで、その回答例を提示しよう。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。