アプリ開発かいはつでも、よ〜く考かんがえよう。キャッシュは大事だいじだよ：現場げんばから学まなぶWebアプリ開発かいはつのトラブルハック（12）（1/2 ページ）

“無駄むだ”より“遅おそい”ものはない

　今回こんかいもパフォーマンスにまつわるトラブルをハックするが、アプリケーションのパフォーマンスチューニングで最もっとも有効ゆうこうな手段しゅだんは「処理しょりを行おこなわない」ことである。何なにもしないことに勝まさる高速こうそく化かは存在そんざいしない。今回こんかいのトラブルでは、インスタンスをキャッシュ化かして、無駄むだな処理しょりを行おこなわないことでチューニングを行おこなう手法しゅほうを紹介しょうかいする。

　しかしながら、往々おうおうにしてチューニングはトレードオフである。そのトレードオフが引ひき起おこす、さらなるトラブルを紹介しょうかいする。

■コンサルティングもトラブルハッカーの仕事しごと

　とあるプロジェクトから1通つうのメールが届とどく。

　「あるJavaで作成さくせいしたリッチアプリケーションのパフォーマンスに問題もんだいを抱かかえている。自分じぶんたちで考かんがえられ得える対策たいさくは講こうじた。しかし、目標もくひょうのパフォーマンスを達成たっせいできない」とのことで、相談そうだんに乗のってほしいそうた。

　こういったケースをメールでやりとりしても“らち”が明あかないため、早速さっそく現場げんばへ急行きゅうこうする。トラブルが発生はっせいした場合ばあいに何なにをするべきなのか、が分わからないプロジェクトは多おおい。そんなプロジェクトのコンサルティングを行おこない、進すすむべき道みちを示しめすのもトラブルハッカーの仕事しごとである。

■まさかXMLが

　早速さっそく現場げんばの担当たんとう者しゃにヒアリングを行おこなう。今回こんかいパフォーマンスが出でていないシステムはJavaリッチアプリケーションであり、サーバとクライアントの間あいだの通信つうしんをXMLで行おこなっている（図ず1）。

図ず1　システム構成こうせい

　また、これまでの調査ちょうさでは、サーバ側がわの処理しょりはさほど速度そくどが遅おそくはなく、クライアント側がわの処理しょりがボトルネックになっているとのことであった。

　SOAPに代表だいひょうされるXMLを用もちいて通信つうしんを行おこなうシステムでは、XML操作そうさに関かんする以下いかの処理しょりがボトルネックになりやすい。

• XMLのパース
• XMLとJavaオブジェクトのマッピング

　XMLの取とり扱あつかいには苦にがい思おもい出でがあるため、真まっ先さきに担当たんとう者しゃへ確認かくにんをしたがXMLに関かんしては「すでに以下いかのようなチューニングを施ほどこした」と伝つたえられた。

• XML入いれ子こ構造こうぞうの簡略かんりゃく化か
• 操作そうさ差分さぶん分ぶんのXMLだけを送信そうしんするように修正しゅうせい

先入観せんにゅうかんは判断はんだんを鈍なまらせる

　先入観せんにゅうかんを持もつと視野しやが狭せまくなって、問題もんだいの本質ほんしつを見失みうしなってしまう。再ふたたび冷静れいせいになり事態じたいを整理せいりする。

• GCの頻度ひんどはさほど高たかくない
• 通信つうしんが発生はっせいする操作そうさを行おこなうとCPU利用りよう率りつが急上昇きゅうじょうしょうする

　以上いじょうから、本ほん連載れんさい第だい1回かい「Webアプリの問題もんだい点てんを「見みえる化か」する7つ道具どうぐ」のトラブル切きり分わけフローに基もとづき、メソッドプロファイラの導入どうにゅうを決定けっていして、処理しょり時間じかんがかかっているメソッドを特定とくていすることにした。

Webアプリの問題もんだい点てんを「見みえる化か」する7つ道具どうぐ (1/3) - ＠IT via kwout

■プロファイラは、何なんでもお見通みとおし

　早速さっそく、フローの手順てじゅん3「メソッドプロファイリング」に基もとづき、あるメソッドプロファイラをアプリケーションにアタッチして、どのメソッドがボトルネックなのかを確認かくにんした。

　また、結果けっかを平均へいきん化かするため通信つうしんを行おこなう操作そうさを10回かい繰くり返かえしたときの結果けっかをプロファイリングした。プロファイリングの結果けっかは図ず2のとおりである。

図ず2　プロファイリングの結果けっか（一部いちぶを再現さいげんしたものです）（画像がぞうをクリックすると拡大かくだいします）

　一見いっけんすると、普通ふつうのプロファイリング結果けっかであるが、よく見みてみると大おおきな問題もんだいに気きが付つく。

　そう、「getInitBillingProps」メソッドの呼よび出だし回数かいすうが実行じっこう回数かいすうの10回かいと一致いっちしているのだ（図ず2の赤あか枠わく参照さんしょう）。

　名前なまえから推測すいそくするにアプリケーション初期しょき化かのためにプロパティファイルのロードを行おこない、プロパティの値ねをインスタンス化かしているようである。メソッドの名前なまえどおりの動作どうさを行おこなっているとすれば、アプリケーションの通信つうしんの操作そうさを10回かい繰くり返かえしたからといって、「getInitBillingProps」メソッドが10回かい実行じっこうされるのは明あきらかにおかしいはずである。

■「getInitBillingProps」メソッドの挙動きょどうを確認かくにん

　まずは、ソースを確認かくにんする。やはりプロパティファイルからプロパティの値ねをオブジェクト化かしているだけである。念ねんのため、忙いそがしそうにしている担当たんとう者しゃを捕つかまえて、メソッドの仕様しようの確認かくにんをした。やはり「getInitBillingProps」メソッドはアプリケーションの初期しょき化かのためにプロパティの値ねをインスタンス化かするためのメソッドらしい。

図ず3　通信つうしん時じの挙動きょどう

　すなわち、このアプリケーションは通信つうしんを行おこなうごとにプロパティファイルにアクセスしていることになる。つまるところ、完全かんぜんに無駄むだな処理しょりを行おこなうのである。これでは、パフォーマンスが出でるはずもない。

　では、こういった状況じょうきょうではどのような解決かいけつ策さくがあるのか？ 読者どくしゃの皆みなさんも考かんがえてみてほしい。次じページで、その回答かいとう例れいを提示ていじしよう。