パフォーマンスチューニングのエンタープライズJavaアプリケーションは、近代のアプリケーションの複雑さとチューニング方法論の欠如のせいで、非常に労力を要することがあり、時に実りのないタスクとなることがあります。近代のエンタープライズアプリケーションは、複数の入力、複数の出力、複雑なフレームワークおよび業務処理エンジンをサポートするという点で、わずか十年前の同等物と大きく異なります。十年前、Webベースのエンタープライズアプリケーションは、Webブラウスからの入力、データベースやレガシーシステムとの相互作用によるバックエンド処理、およびWebブラウザ（HTML）に戻される出力を期待することができました。現在、入力は、HTMLブラウザ、シッククライアント、モバイル機器、またはWebサービスの形式でもたらされます。これは、さまざまなアーキテクチャの1つまたはポータルコンテナで動作するサーブレットを通過でき、次にはそれがEnterprise Bean、外部Webサービス、またはビジネスルールエンジンへのdelegate（委譲）処理を呼び出すことができます。これらの各コンポーネントは、コンテンツ管理システム、キャッシュ層、多量のデータベース、およびレガシーシステムとやりとりすることが可能です。出力は通常、プレゼンテーションに依存しない形式で含まれ、後にHTML、XML、WML、またはクライアントアプリケーションが期待するその他の形式に変換されます。近代のアプリケーションには昔よりも多くの可動部分と「ブラックボックス」があり、重大なパフォーマンスチューニング課題となっています。
複雑さの増大に加え、パフォーマンスチューニングは依然として「サイエンス（科学）」というより「アート（芸術）」であり、大半のパフォーマンスチューニングガイドは、時に不可解でエンドユーザー体験に影響を与えるかどうか分からないパフォーマンスメトリックに焦点を合わせています。この記事では、パフォーマンスチューニングのプロセスを「サイエンス」の域に移行することを試みます。そのために、「待機ポイント」すなわちリクエストを待機させる可能性のあるアプリケーション部分に関してアプリケーションのアーキテクチャを分析することでエンドユーザー体験に焦点を合わせた、繰り返し可能なプロセスを提示します。要するに、待機ベースのチューニングは、パフォーマンスエンジニアがエンドユーザー体験を最適化することで、測定可能なパフォーマンスの向上を迅速に実現することを可能にします。
パフォーマンスチューニングプロセス
待機ベースのチューニングおよび待機ポイント分析の詳細をレビューする前に、このセクションでは、効果的なパフォーマンスチューニングのプロセスの概要、すなわちロードマップを示します。パフォーマンスチューニングは、簡単に次の4つのステップに要約できます。
- 負荷テスト
- コンテナチューニング
- アプリケーションチューニング
- イテレート（反復）
多くのコンピュータサイエンスと同様に、パフォーマンスチューニングは反復プロセスです。パフォーマンスチューニングはまず、バランスの取れたサービスリクエストと代表的なサービスリクエストの両方を含む、適切な負荷テストを作成することから始めます。これは、コンテナチューニングの実行によって満たされます。コンテナがチューニングされると、負荷の増加によってアプリケーションのボトルネックが浮上します。アプリケーションのボトルネックが特定され解決されると、アプリケーションは違った動作を取り、コンテナの再チューニングを必要とします。コンテナとアプリケーションチューニングの繰り返しのプロセスは、パフォーマンスが許容範囲になるまで（またはプロジェクトが時間切れになりリリースが必要になるまで）繰り返すことができます。
負荷テスト方法論
パフォーマンスチューニングの実行を開始できるようになるための必要条件は、適切な負荷テストスイートを作成することです。負荷テストは、次の2つの点に対処する必要があります。
- 負荷は、エンドユーザーが実行している（実行すると見込まれる）ことの代表でなくてはならない
- 負荷は、エンドユーザーの動作を再現するために同じ割合でバランスが取れていなくてはならない
つまり、負荷は、エンドユーザーアクションを、エンドユーザーが実行するのと同じ割合で再現する必要があります。エンドユーザーアクションのバランスを取ることの重要性を明らかにするために、次のシナリオについて考察しましょう。保険金請求部門で、従業員は次の動作を示しています。
- ユーザーは8amにログインする
- 平均してユーザーは朝に5件の請求を処理する
- ユーザーの約80%は昼食に出掛ける前にログオフし忘れるため、セッションが切れる
- 昼食後、ユーザーはアプリケーションに再ログインする
- ユーザーは午後に平均5件の請求を処理する
- ユーザーは退社前に2つのレポートを生成する
- ユーザーの80%は退社前にシステムからログアウトする
この例は、実際のアプリケーションを単純化し過ぎているかもしれませんが、サービスリクエスト間のバランスを確立するには十分です。このシナリオは、次のバランスを示しています。2回のログイン、10件の請求、2つのレポート、および1回のログアウト、です。
負荷ジェネレータがさまざまなサービスリクエスト間で均等に負荷を分散したらどうなるでしょうか? このようなシナリオでは、ユーザーのログインとログアウト機能が、請求処理機能と同じ量の負荷を受けることになります。1000人の同時ユーザーの予想負荷を考えると、ログイン機能はすぐに崩壊すると考えられ、組織は、決して受けることのない負荷を処理できるログインコンポーネントの増築に金を投資することになります。さらに悪いことには、チューニングの取り組みは、このシナリオで最大のボトルネックを示すログイン機能のチューニングに焦点を合わせますが、請求処理機能を犠牲にします。つまり、アンバランスな負荷は、決して受けることのない負荷に対応するアプリケーション部分をチューニングする一方で、受ける負荷に対応するアプリケーション部分をチューニングしないことにつながる可能性があります!
アプリケーションについてどの負荷のバランスを取り、代表にするかの決定は、既存のアプリケーション（または既存のアプリケーションの新バージョン）を検証する場合と新しいアプリケーションを構築する場合とで異なります。
既存のアプリケーション
既存のアプリケーションは、その新しいアプリケーション同等物よりも明白な利点を示します。つまり、実際のユーザー動作を実稼動環境で観察できます。リクエストの性質およびそれらをアプリケーションでどのように特定するかに応じて、エンドユーザーの動作を特定するオプションが2つあります。
- アクセスログ
- エンドユーザー体験モニター
ほとんどのWebベースアプリケーションに関して、アクセスログは、サービスリクエストの性質と相対的バランスの発見を容易にするだけの十分な洞察力を与えます。Webサーバーは、エンドユーザーのリクエスト情報を取得してそれを「アクセスログ」と呼ばれるログファイル（ファイルは一般に「access.log」と名前が付けられるため）に保存するように設定できます。アクセスログを使用してユーザー動作を特定できるようになる鍵は、アプリケーションの相互作用をURIで区別できる必要があるということです。たとえば、前の例のアクションが「/login.do」、「/processClaim.do」、「/logout.do」のようなURIと同一視された場合、アクセスログファイル内でそれらを非常に簡単に見つけることができ、相対的バランスを決定できるでしょう。さらに、頻度の高いURI順にアクセスログファイルをソートすることで、リクエストの上位「n」パーセントがすぐに特定されるでしょう。ここで、「n」はおよそ80%である必要があります。
アクセスログは、手動で検証できる（あまり有意義ではないタスク）、プログラムで解析できる、またはツールで分析できる、テキストファイルです。多数の商用ソリューションがありますが、Quest SoftwareにFunnel Web Analyzer(リンク)と呼ばれる製品があります。これは数年前に生産が終了しましたが、大衆の要望により、フリーフェアとしてリニューアルしました。Funnel Web Analyzerは、ほとんどのアクセスログファイルを分析でき、適切な負荷テストの作成に必要な情報を提供できます。
一部のアプリケーションはそれほど単純ではなく、ユーザーの相互作用は単純なURIで容易に特定することはできません。たとえば、XMLペイロードを受け入れる単一のフロントコントローラサーブレットを持つアプリケーションについて考えましょう。処理するビジネスロジックは、ペイロード内に格納されています。このようなシナリオでは、満足のいくビジネスケースを決定するためにそのペイロードを調べる別のツールが必要になります。これは、サーブレットフィルタを使用して手動で構築されるか、エンドユーザー体験モニターというハードウェアデバイスを必要とする場合があります。
これはユーザー動作の取得方法に関係なく、パフォーマンスチューニングの実行を開始する前の中心的な必要条件となります。
新しいアプリケーション
新しいアプリケーションは、分析するエンドユーザー動作が存在しないために独自の課題を示します。図1に示したように、新しいアプリケーションにおいてユーザー動作を特定する際に考慮すべき3つのステップがあります。
図1 新しいアプリケーションのエンドユーザー動作の推測
最初のステップは、エンドユーザーが実行すると予測されることを推測することです。このステップは「take a guess（当ててみる）」という正式な言い方をしますが、経験に基づいた推測です。この推測は、アプリケーションビジネスオーナーとアプリケーションテクニカルオーナーの二者間の話し合いからもたらされる必要があります。アプリケーションビジネスオーナーは、一般的にプロダクトマネージャーであり、エンドユーザーがアプリケーションをどのように使用すると見込まれるかを詳述する責任を担います。たとえば、エンドユーザーがログイン、5つの請求の処理、タイムアウト、5つ以上の請求のプロセス、2つのレポートの生成、ログアウトを行うと見込まれることを報告します。アプリケーションテクニカルオーナーは、アーキテクトやテクニカルリーダーの場合があり、ビジネス相互作用の要約リストを負荷テストの作成に必要な技術ステップに変換する責任を担います。たとえば、ログインが「/login.do」URIを通じて達成され、請求処理のステップを構成する5つのURIが存在することを報告します。同時に、各個人（または大規模プロジェクトでのグループや委員会）は、ベースライン負荷テストを作成するのに十分な情報を提供する必要があります。
負荷テストが作成され、アプリケーションおよびコンテナをチューニングするために使用され、アプリケーションが実稼働環境に配備されても、チューニング作業は完了ではありません。この負荷テスト方法論の次のステップは、負荷テストスイートを検証することです。これは通常、多段階のアクティビティです。
- スモークテスト検証: 運用の最初の1、2週間における実稼動のエンドユーザー動作に対する推測を検証します。この検証ステップは、推測ステップ時に大きな間違いをしていないことを確認するために必要です。
- プロダクション検証: 一部のアプリケーションでは、エンドユーザーが一貫した使用パターンになるまでに時間が必要とされます。この時間はアプリケーションに依存しており、1カ月または3カ月かかる場合もありますが、ユーザーがアプリケーションの使用に慣れたら推測に対してエンドユーザー動作を検証することは重要です。
- リグレッション検証: ユーザー動作の変化や、エンドユーザー動作を変える新機能や新しいワークフローが導入される場合に備えて、アプリケーションの実稼動ライフサイクル全体を通して定期的にユーザーの動作を検証するためのベストプラクティスです。
最後のステップは、一般に見落とされますが、振り返りです。振り返りを通じてのみ、ユーザー動作がよりよく理解されるようになり、推測がその後のアプリケーションで改善するため、実際のエンドユーザー動作に対する推測の精度について振り返ることは重要です。振り返りなしでは、何度も同じミスを繰り返し、結局はチューニングの作業量が増加してしまうことになります。
待機ベースのチューニング
負荷テストを片手に、チューニング労力が最適に費やされる場所を決定するときです。多くのチューニングガイドは、「パフォーマンス率」またはメトリック間の関係に関与しています。たとえば、チューニングガイドは、キャッシュヒット率が80%以上になることを重視する場合、ヒット率が80%になるまでキャッシュサイズを調節しながらアプリケーションの負荷テストを行います。その後、リスト内の次のメトリックに移動し、一方で新しいメトリックをチューニングしても前のメトリックのチューニングが無効にならないことを常に検証します。
これは困難なタスクというだけでなく、非常に実りのない場合があります。たとえば、キャッシュヒット率を80%にチューニングすることは良いことかもしれませんが、次のようなより重要な問題があります。
- アプリケーションはどのくらいキャッシュに依存しているか（リクエストの何パーセントがキャッシュと相互作用しているか）?
- これらのリクエストはアプリケーションの他のリクエストに関してどれくらい重要であるか?
- キャッシュされるアイテムの性質はどのようなものか? それらはそもそもキャッシュされるべきか?
待機ベースのチューニングは、アプリケーションのビジネス相互作用を分析すること、そのビジネス相互作用を実装する基本アーキテクチャ、およびそのビジネス相互作用の処理を最適化することの概念を促進します。最初のステップは、リクエストを満たすために採用されたテクノロジーを特定するため、アプリケーションのアーキテクチャを分析することです。採用された各テクノロジーは、「待機ポイント」、すなわちリクエストが処理を継続する前に何かを待機しなければならない可能性のあるアプリケーション内の場所を示すことがあります。たとえば、リクエストはデータベースクエリーを実行する場合、接続プールからデータベース接続を取得する必要があるとします。接続プールに利用可能な接続がない場合、そのリクエストは接続が利用可能になるまで待機する必要があります。同様に、リクエストがWebサービスを呼び出す場合、そのWebサービスにはリクエストキュー（着信リクエストを処理するスレッドプールに関連する）があり、これは、スレッドが利用可能になるまでリクエストに待機させる可能性があります。
待機ポイント分析と呼ばれるこの分析から、2種類の待機ポイントを特定できます。
- 階層ベースの待機ポイント
- テクノロジーベースの待機ポイント
このセクションは、待機ポイントアーキテクチャ分析（Wait-Point Architectural Analysis）をレビューすることから開始し、次に待機ポイントのさまざまな種類について調査します。
待機ポイントアーキテクチャ分析
この議論から離れた最も重要な点は、パフォーマンスチューニングが、チューニングされるアプリケーションのアーキテクチャとの関連において実行されなくてはならないということです。これは、チューニングパフォーマンス率が役に立たない場合がある理由の1つです。パフォーマンスメトリックをベストプラクティス設定にチューニングすることは、チューニングされるアプリケーションにとって良い場合と悪い場合があります。また、エンドユーザー体験にプラスの影響を与える場合と与えない場合があります。
待機ポイント分析は、リクエストに待機させる可能性のあるリソースを特定するために、アプリケーションを通じて主要なリクエスト処理パスを分析するプロセスです。待機ポイント分析の実行に採用すべき最も効果的な戦略は、アプリケーションにおけるコアの処理パスを特定し、それらのパスをホワイトボードに記録することです。リクエストがあいだを通過する可能性のあるすべての階層、リクエストが相互作用する可能性のあるすべての外部サービス、プールされるすべてのオブジェクト、キャッシュされるすべてのオブジェクトを含めてください。
階層ベースの待機ポイント
リクエストが、Web層とビジネス層との間など、物理層を通過するとき、またはWebサービスを呼び出す場合など、外部サーバーに呼び出しを行うときはいつでも、その移行に関連付けされた暗黙の待機ポイントが存在します。サーバーがもし一度に1つのリクエストしか受け付けなかったら効率的でないということを考慮し、マルチスレッド戦略を実施しています。通常、サーバーは着信リクエストをソケットでリッスンします。サーバーはリクエストを受信すると、そのリクエストをすぐにリクエストキューに配置し、さらなる着信リクエストをリスンするために戻ります。リクエストキューには、キューからリクエストを取り出してそれを処理する関連スレッドプールがあります。図2は、このプロセスがWebサーバー、ダイナミックWeb層、およびビジネス層の3つの層でどのように実行されるのかを示しています。
図2 階層ベースの待機ポイント
階層を通過するリクエストのアクションには、関連スレッドプールによって提供されるリクエストキューが伴うため、スレッドプールは潜在的に重要な待機ポイントを示します。各スレッドプールのサイズは、次の考慮事項によってチューニングする必要があります。
- プールは、着信リクエストが不必要にスレッドを待機する必要がない十分な大きさでなくてはならない
- プールは、サーバーを飽和させるほど大きくなってはならない。スレッドが多すぎると、サーバーは個々のスレッドコンテキスト間を切り替えるのに時間がかかり、リクエストを処理する時間が減ります。これは、高いCPU使用率とリクエストスループットの減少という特徴を表します。
- プールは、相互作用するどんなバックエンドリソースも飽和させないように最適なサイズでなくてはならない。たとえば、データベースが各サーバーから50のリクエストしかサポートできない場合、そのサーバーは50以上のリクエストをデータベースに送信すべきではありません。
サーバーのスレッドプールの最適なサイズは、使用率を最大限にするが飽和させることがないよう、限定的依存性に十分な負荷を生成するスレッド数です。限定的依存性プールのサイズに関する詳細については、下記の「後方チューニング」を参照してください。
テクノロジーベースの待機ポイント
階層ベースの待機ポイントはサーバー間のリクエストの移動に関係している一方で、テクノロジーベースの待機ポイントは各サーバーの内部構造を通じた効率的なリクエストの移動に関係しています。階層ベースのチューニングは、IBMのQueue Tuning(リンク)と多少類似しており、アプリケーションをチューニングする効果的な最初のステップですが、アプリケーションサーバーの内部構造のチューニングを怠ると、アプリケーションのパフォーマンスに大きな悪影響をもたらすことがあります。これは、最適な負荷量をデータベースに送るためにJDBC接続プールをチューニングするが、実行されるSQLのレビューを怠ることに類似しています。クエリーがそれぞれ100万件のレコードを含む10個のテーブルを結合する場合、最適な負荷は2つの接続かもしれませんが、クエリーが最適化された場合、データベースは200の接続に対応できる場合があります。
アプリケーションサーバーと、アプリケーションが利用できる潜在的テクノロジーの内部に目を向けると、次のような共通のテクノロジーベースの待機ポイントがもたらされます。
- プールされたオブジェクト（Stateless Session Beanやアプリケーションがプールするビジネスオブジェクトなど）
- キャッシュインフラストラクチャ
- 永続ストレージまたは外部依存性プール
- メッセージングインフラストラクチャ
- ガーベジコレクション
多くの場合、Stateless Session Beanのプールサイズは、プールサイズが手動で不適切に設定されていない限り、アプリケーションサーバーによって最適化され、重要な待機ポイントを示すことはありません。ただし、手動でのサイズ設定が必要な、アプリケーションでプールされるオブジェクトがあります。そして、これらは有効な待機ポイントを示すことができます。アプリケーションはプールされたリソースを必要とする場合、プールからそのリソースのインスタンスを取得し、それを使用し、次にそれをプールに返さなくてはならないということを考えてください。プールのサイズがあまりに小さく、すべてのオブジェクトインスタンスが使用中の場合、リクエストは、オブジェクトが利用可能になるまで待機せざるを得なくなります。プールされたリソースを待機すると、応答時間は（明らかに）増加しますが、ますます多くのリクエストが、プールされたリソースを待機してバックアップをとり続けると、重大なパフォーマンスの低下が生じる場合があります。その一方で、プールのサイズがあまりに大きい場合、過度にメモリを消費し、JVMのパフォーマンス全体に悪影響を与える場合があります。このように二律背反（トレードオフ）であるため、これらのプールの最適なサイズは、プールの使用率の徹底的な分析後にしか決定できません。
プールされたオブジェクトはステートレスです。つまり、アプリケーションがプールからどのインスタンスを取得しても構いません。どのインスタンスでも十分です。一方、キャッシュされたオブジェクトはステートフルです。つまり、アプリケーションはキャッシュからオブジェクトをリクエストする場合、特定のインスタンスが必要です。この違いを示す非常に大雑把なたとえがこれです: 多くの人々の日常に起こる2つの一般的な活動を考えてください: スーパーマーケットで買い物をすることと、学校に子供を迎えに行くことです。スーパーマーケットでは、レジ係はどんな顧客でもチェックアウトでき、顧客はどのレジ係を選んでも構いません。どのレジ係でも十分です。したがって、レジ係はプールされます。しかし、学校に子供を迎えに行く場合、親は自分の子供が必要であり、別の子供では不十分です。したがって、子供はキャッシュされます。
そういう訳で、キャッシュは固有のチューニング課題を示します。キャッシュの目的は、単純な見方をすると、オブジェクトを、要求に応じて取得するのではなく、メモリ内にローカルに保管し、それらをアプリケーションで容易に利用可能にすることです。適切にサイズ設定されたキャッシュは、オブジェクトをロードするためにリモート呼び出しを行うことにより著しいパフォーマンスの向上を実現できます。ただし、不適切にサイズ設定されたキャッシュは、著しいパフォーマンス妨害をもたらす恐れがあります。キャッシュはステートフルなオブジェクトを持つため、キャッシュでは、アクセス頻度の高いオブジェクトをキャッシュに維持して、通過するアクセス頻度の低いオブジェクト用の十分な追加スペースを提供することが重要です。サイズが小さすぎるキャッシュにアクセスするリクエストの動作を考えてください。
- リクエストは、オブジェクトがないかキャッシュを調べますが、キャッシュ内にありません
- リクエストは、オブジェクトのデータについて外部リソースにクエリーを実行し、そのデータからオブジェクトを生成する必要があります
- キャッシュは通常、直近にアクセスされたデータを維持するように作られているため、新しいアイテム（現在アクセスされているもの）がキャッシュに追加される必要があります
- ただしキャッシュが満杯の場合は、「Least Recently Used（最長未使用時間）」アルゴリズムのようなアルゴリズムを使用して、キャッシュから削除するオブジェクトを選択しなくてはなりません。
- キャッシュされたオブジェクトのステートを外部リソースに存続させない場合は、外部リソースはオブジェクトが破棄される前に更新されなくてはなりません
- これで、新しいオブジェクトをキャッシュに追加できます
- 新しいオブジェクトは最終的にリクエストに返すことができます
これは厄介なプロセスであり、リクエストの大部分がこれらの各ステップを実行する必要がある場合、キャッシュは本当にパフォーマンスを妨げるでしょう。キャッシュは、キャッシュ「ミス」を最小限にする十分なサイズでなくてはなりませんが（ここで、ミスは、前述の7つの各ステップを実行することと本質的に同じです）、過度にJVMメモリを消費するほど大きなサイズであってはなりません。キャッシュが効率性のために十分に大きい必要がある場合は、キャッシュされるオブジェクトの性質と、そもそもそれらをキャッシュすべきかどうかについて再考することが重要です。
オブジェクトプールと同様に、データベース接続プールなどの外部リソースプールは、接続がプール内で利用可能になるまで待機しなくてすむだけの十分なサイズでなくてはなりませんが、アプリケーションが外部リソースを飽和させるほど大きなサイズであってはなりません。下記の「後方チューニング」セクションではこれらのプールの最適なサイズを決定する方法について説明しますが、このセクションの中で、プールが別の待機ポイントを示すことに注意してください。
メッセージングインフラストラクチャのチューニングは、この記事の範囲をはるかに超えており、MSMQ、MQSeries、TIBCOなどの主要製品間で実装が大幅に異なりますが、アプリケーションはメッセージングサーバーと相互作用する場合は、適切にチューニングされる必要があるか待機ポイントを示すことができるということに注意してください。
JVMのパフォーマンスに大きな影響を与える可能性がある最後の待機ポイントは、ガーベジコレクションです。この記事で説明する待機ポイント分析プロセス（リクエストに待機させる可能性があるテクノロジーを特定するという意図でリクエストを調査する）にはうまく合いませんが、パフォーマンスにそのような大きな影響を与える可能性があるという理由で、ここに記載しています。さまざまなJVM実装やさまざまなガーベジコレクション戦略が、ガーベジコレクションの実行方法に影響しますが、多くの場合、主要なガーベジコレクション（mark-sweep-compactガーベジコレクション）は、ガーベジコレクションが完了するまで、JVM全体をフリーズさせることができます。JVMに対する最大のパフォーマンス改善の1つは、ガーベジコレクション動作を最適化することです。ガーベジコレクションの詳細については、GeekCap discussions on Application Infrastructure Tuning(リンク)に参加してください。
後方チューニング
階層ベースおよびテクノロジーベースの待機ポイントのすべてを呼び出したので、最後のステップは、各待機ポイントの設定を最適化することです。このステップは、「後方チューニング（tuning backwards）」と呼ばれることもあり、概念的に非常にシンプルです。
- すべての階層ベースの待機ポイントと外部依存性プールを解放します。つまり、サーバーを通過するために過度の負荷を許可するようにそれらを設定します。
- アプリケーションに対してバランスの取れた代表的なサービスリクエストを生成します。
- 最初に飽和させる待機ポイントを特定します。これは一般に、データベースなどの、外部依存性になります。
- 限定的待機ポイントの設定を、飽和させることなく外部依存性に渡すだけの十分な負荷を許可するように強化します。
- 他のすべての階層ベースの待機ポイントを、限定的待機ポイントを最小限にするがリクエストを待機させないサーバーを通じてのみ十分な負荷を送信するようにチューニングします。
- 他のすべてのオブジェクトが、Webサーバーなどの、ビジネスロジックライトな層で待機できるようにします。
ここでの原則は、アプリケーションが、飽和を引き起こすことなく使用率を最大にする負荷量のみを外部依存性に送るべきであるということです。そして、他のすべての待機ポイントは、限定的待機ポイントを最大にするだけの十分な負荷のみを渡すように設定するべきであるということです。たとえば、データベースが、各アプリケーションサーバーからの50の接続によって飽和状態になる場合、データベース接続プールは50未満のリクエストをデータベースに送信するように設定される必要があります（たとえば、40または45の接続を含むようにプールを設定します）。次に、80のスレッドが40のデータベース接続を生成する場合、アプリケーションのスレッドプールは80に設定する必要があります。最後に、Webサーバーはいつであれ各アプリケーションサーバーに80以上のリクエストを送信することはできません。
オブジェクトプール、キャッシュ、ガーベジコレクションなどのテクノロジーベースの待機ポイントはすべて、できるだけ早くサーバーや階層ベースの待機ポイント間を通過できるようにリクエストのスループットを最大限にするようにチューニングされなくてはなりません。
まとめ
パフォーマンスチューニングは、かつて「サイエンス（科学）」というより「アート（芸術）」でしたが、抽象的な分析と試行錯誤の組み合わせの後、待機ベースのチューニングはその実行をはるかに科学的かつはるかに効果的にするということが分かりました。待機ベースのチューニングは、リクエストを待機させる可能性のある、アーキテクチャで採用されたテクノロジーを特定するために、アプリケーションのアーキテクチャの待機ポイント分析を実行することから開始します。待機ポイントは2種類あります。アプリケーションの階層間の移行を示す階層ベースの待機ポイントと、パフォーマンスを向上または妨害する可能性がある、キャッシュ、プール、メッセージングインフラストラクチャなどのテクノロジー機能であるテクノロジーベースの待機ポイントです。待機ポイントセットが特定されると、チューニングプロセスは、すべての階層ベースの待機ポイントと外部依存性プールを解放し、アプリケーションに対してバランスの取れた代表的な負荷を生成し、後方チューニングを行い、待機ポイントをリクエストの最弱リンクのパフォーマンスを最大化するが飽和させないように強化することで、実施されます。
待機ベースのチューニングは、効果的なだけでなく、測定可能なパフォーマンスの向上をパフォーマンスエンジニアが非常に迅速に実現できるようにするということを、実稼働環境で何度となくそれ自体が証明しています。
著者について
Steven Haines氏は、グローバルな開発コミュニティへのeラーニングソリューションの提供に重点的に取り組んでいる、GeekCap, Inc.(リンク)の創設者兼CEOです。特に、パフォーマンステストやパフォーマンスチューニングのようなマニアックなものを扱う傾向があります。eラーニングソリューションの他、GeekCapは無料のテクノロジーフォーラム(リンク)や、学習コースや、開発者が技術キャリアを発展させたり新しいテクノロジーを学習したりするのに役立つその他のリソースを提供しています。また、GeekCapは、ホワイトペーパーや技術説明などのマーケティング促進資料を生成するサービスや、市場分析や戦略的ポジショニングなどのビジネスサービスを提供します。Haines氏は、1ダース以上のホワイトペーパーと、『Pro Java EE 5 Performance Management and Optimization』（Apress、2006）、『Java 2 Primer Plus』（SAMS、2002）、『Java 2 From Scratch』（QUE、1999）といった本の著者であり、また、InformIT.com(リンク)のJavaホストであり、InfoQ.com(サイト)のJavaコミュニティエディタでもあります。日中、Haines氏はDisneyの請負業者としてDisneyのWebサイトに次世代アーキテクチャを実装することを担当するチームで働いています。以前は、Quest Softwareでパフォーマンス監視・分析ソフトウェアを設計するJavaドメイン専門家として7年間を過ごしました。また、カリフォルニア大学アーバイン校およびラーニングツリー大学でJavaプログラミング全般を教えていました。Haines氏の連絡先はsteve at geekcap.comです。
原文はこちらです：http://www.infoq.com/articles/Wait-Based-Tuning-Steven-Haines
（このArticleは2008年10月6日に原文が掲載されました）