序文
実際、パフォーマンスはユーザビリティの重要な側面だ。 だが、とても誤解されている。 この本ではマーキテクトとターキテクトが話し合い、パフォーマンスに関する条件をしっかり決めることと、開発チームがマーキテクトに提供すべきパフォーマンス条件を見せることにフォーカスを当てる。
内容をクリアにしよう
具体的にするために表10-1を使う。 システムのパフォーマンス条件のために計算したい内容を言ってみよう。 最初のステップは特定もしくはシステムのパフォーマンス条件をFixするすることだ。
これは下記の依存性のあるものを特定できる。 ・ハードウェア ・ディスク容量 ・メモリサイズ ・オペレーティングシステム ・データベース ・ウェブサーバ ・必要とされる他のアプリケーション
構成のために、以下を考えてみよう
表10-1 パフォーマンス詳細
スループット: 単位時間あたりのビットまたはトランザクション数 パフォーマンス: 単位あたりの時間。スループットの逆 性能: レスポンスの待ち時間 キャパシティー: 一定のレベルのパフォーマンス下で与えられた構成でのサポートできるユーザ数 スケーラビリティ: ハードウェアを追加することでのキャパシティーの増加することができる能力 信頼性: システムが停止することなく動作できる時間数 応答時間: リクエストを処理するトータルの知覚時間。感覚的・主観的な評価・パフォーマンスに関する人間的な定義
Below: テストのためだけの最低限構成 Minimum: 最小構成。標的市場の平均的な構成でなくてはならない Average: 市場にマッチした構成 Ideal: アーリアダプターアダプターとインフルエンサーの市場構成 Max: 構築できるベストなシステム
次のステップはテストしたいトランザクションとオペレーションを参照するデータをともなって明確にすることだ。もしテストしたいパフォーマンスデータがあったら、同じデータをすべてのテストに使用 すべきだ。
例として、筆者はシステムがサーバをベースとし、8章で記載されている方法で構築されていることとする。一旦サーバが動き出したら、テストとドライバードライバーにリクエストをシミュレートできる。 特定のリクエストに対するシステムの応答時間を0.1秒単位で定義してみよう。 それがパフォーマンスのベースレベルとなる。 もし開発したテストドライバドライバがシステムで秒間10リクエストまでシミュレートでき、同じパフォーマンスで24時間止まらなかったら、信頼性をもっていると言っていい。
トランザクションを増やすことを始めるまえに、もっと興味的なことに気づくかもしれない。 分間600回を超えるトランザクションの場合にシステムが停止する想定だとする。 現実にはシステムはこれを超えるトランザクション数に耐えられるかもしれない。 これはトータルのシステムにおいて、応答速度とスループットの違いを表している。 なぜなら様々なトランザクションは様々なレイヤーを通過し、異なるコンポーネントに存在するからだ。
筆者がもっと思っていることは、トランザクションのロジックは永続ストアと分離できることだ。 これはさらにマシンを増やすことができるようにすべきであることを意味している。 マシンを追加したら、もし一台だとしても、すべてのトランザクションサーバが一つのデータベースを共有する。 分間2500トランザクションをシステム停止なくハンドルできることが分かっている。 これはドロップリクエストとなるのだが、 これはシステムのスケーラビリティの物差しとなる。 様々なパフォーマンス要因を改善するためハードウェアの追加の能力となる。 もしこれを超える改善ができなかったとしても、データベースサーバの最大値を知ることができる。 これを改善することはサーバを特殊な方法で調整することを必要とし、それはハードウェアに特殊なファイルシステムをインストールしたり、データベースのベンダーを変更したり、SQLクエリのプロファイリングなどでチューニングもしくは最適化のような方法になる。
この例のメカニズムはパフォーマンスの改善するために、様々なリミットを想定することにシフトしている。 これは複雑なシステム内で共通だ。 メモリを増やせばパフォーマンスはもっと良くなるだろうし、それは早いプロセッサーや早いディスクハードウェアでも同様だ。
システムが明確な線形なパフォーマンスではないことを見つけるかもしれない。 実際には複雑なシステムが明確な線形なカーブになることはめったにない。 多くの場合、小さなエリアで線形なレスポンスを得て他では様々なカーブを描くだろう。 もしシステムが許容範囲を超えてフェイルオーバーしても驚てはいけない。 これはスケーラブルなシステムのための理由なのだ。(許容できるパフォーマンスレベルの増加をハードウェアに投げることができる)
筆者の例ではそれゆえドライバプログラムが同じフォーマットのリクエストを送ることを想定している。これは現実的でないが、多くのバッチプロセスでないサーバサイドのシステムは一時的に集中的なアクセスがありうる。 サーバにリクエストがキューされたら、停止することのない安定したスループットよりも非常に大きな集中的なアクセスをハンドルする可能性がある。 例として、1秒間に1400リクエストをハンドルできるかもしれないし同様につぎの1秒間はリクエストが来ないかもしれない。異なるサーバは処理できるリクエストの数に違いがあるので、処理できるリミットを知っておくのは良いアイデアだ。 それはサーバが処理できる最大アクセスを与えることができるし、信頼性の他の要因でもある。
システムの感覚的なレスポンスタイムは定義したパフォーマンスと一致しないかもしれない。 パフォーマンスはユーザインターフェースよりも下のレイヤーで明示的に図るべきで、それはユーザインターフェースのレイヤーが追加的なプロセスを追加できるし、パフォーマンスの実際の一部として考えられているものを変更できるからだ。 さらにレスポンスタイムは前もって知ることが難しい。 それでもレスポンスタイム重要だが、良いレスポンスタイムの問題はシステムに対する感覚的なものと使いやすさの能力に関係するからだ。 秒以下のレスポンスタイムは良く、システムがユーザのニーズに即座に返答することを知覚させることを必要とする。 5秒から10秒よりも少ない値のレスポンスタイムは、平均的なユーザが割り込みのフローを感がないことを必要とする。 もし10秒以上のレスポンスタイムはユーザのフォーカスを失うかもしれない。
信頼性はまたエラーのハンドリング扱う。 もしサーバがピークロードを超えてクラッシュしたら、サーバが処理しきれないメッセージをエラーコードに含めて送信するか、ユーザのログインを拒否しないと信頼性としては落ちるだろう。
システム上のトランザクションや処理が同じ種類のものだけであることはあまりないことを知っておくことだ。 多くのシステムが多くの処理をサポートし、それぞれは異なる処理時間とリソースを扱い、パフォーマンスを測定する理想的な方法は、システムの平均的なユーザの影響を理解する助けとなるユーザモデルを定義することだ。 本の作者の中にはシステムの使用方法の洗練されたモデルを進めるものいるが、これはリクエストが均等にランダムな場合に有効なだけなので、ランダムモデルはミスリードするデータを与える。 良いユーザモデルデータのための良いソースはシステムの本番環境での操作に関連づいたログファイルだ。
システムのテストの複雑さについて、システムのパフォーマンスを保守的に見積もることを学ぶべきだ。 実際の環境では開発環境下とは異なることがあるので、予期しない結果を生む可能性がある。
マーキテクトが本当に欲しいパフォーマンスについて
マーキテクトが本当に欲しいものは最速の可能性を持ったシステムと考えがちだが、これは多くの場合本当だ、もちろんみんなそう思っている。 良いエンジニアは無駄を嫌うし、低速なパフォーマンスはあまり評価しない。 また低速なパフォーマンスは顧客に有害だし、不必要でほしくない機能を購入させることになる。 だが、最速のシステムはマーキテクトが本当に欲しいものではないのだ。
マーキテクトが本当に欲しいものは有限的で信頼性があり、上記のパフォーマンスに関連する質問に明確に答えたものだ。
筆者が意味するものを描くと、様々なパフォーマンス属性についてのカスタマーから受け取る質問がそれだ。 それぞれのこれらの質問は特定のものに関連するもので、カスタマーが定義するシステム構成でもある。
同時使用ユーザ数・コネクション数・セッション数をシステムでサポートしているか。 所有するハードウェアがどれくらいのトランザクションを処理できるのか。
マーキテクトがそのような質問の良い答えを必要とする最大の理由は多くの時間顧客は低速なパフォーマンスクエリを待てないからだ。 その代わりに、顧客の環境と顧客のニーズの基本的な理解とインフラのサポートの必要を作成する助けを訪ねることを望んでいる。 マーキテクトは返答する方法を必要としているのだ。 筆者の意味を理解するために、以下の質問を考えてみよう。 実際の顧客のリクエストを抽象化したものだ。
私たちは200のアクティブかつ500のカジュアルなユーザを持っている。どのハードウェア構成がこれらのユーザをサポートするためにお勧めか?
新規製品のリリースの際に一時間に800ダウンロードのサポートの必要なシステムを見積もってほしい。
システムは初期時に年間250万アクセスを想定し、年率25%で増える予定だ。向こう3年間の必要なハードウェアの見積もりとシステムの稼働率が98.5%を保つことを想定したデザインを確認してほしい。
もしデータベースサイズが予期したものよりも早く増えた場合、システムにどのようなインパクトがあるか。ボトルネックはどこか、システムの処理を拡大するにはどうするか。
このような質問は長い複雑なセールスプロセスで作られたものだ。 それらに答えるには顧客から追加となる情報を通常必要とする。しかし、絶対的にはマーキテクトは正確な答えを提供できる必須データを持つべきだ。
この情報をコミュニケーションする効率的な方法の一つとして、ケーススタディやホワイトペーパや付属のパフォーマンスシナリオがある。これらは様々な環境下でのパフォーマンスを見積もることができる。
マーキテクトによって公開されているすべてのパフォーマンスデータはリリース時や推奨するシステム構成のハードウェアの積極的な変更の場合に再計算しないといけない。 この最後のポイントは特に重要だ。 顧客にとって、ハードウェアベンダからの整った情報はパフォーマンスの継続的な改善を期待させるからだ。 もしエンドユーザが古いソフトウェアを新しいコンピュータにインストールしていても問題ではないし、フォーチュン2000の法人が最新バージョンのCRMを新しいマルチプロセッサーサーバにインストールしたとしても、同じだ。 新しいハードウェアを調査するときはいつでもパフォーマンスの改善を期待するものだ。
もちろん新規リリース時に既存のソフトウェアが既存のハードウェアではっきりとして性能改善をすることを期待もするが、これはチャレンジだが、しかし、パフォーマンスの悪化はシリアスなカスタマーの不満足となる。 パフォーマンスはいつも問題だ。
ユーザへの応答
ユーザビリティのアドバイスの無限な部分の一つはシステムは即座に返答しない場合、フィードバックのメカニズムを必要となることだ。 概して、良いユーザのフィードバックと問題とアプリケーションとシステムの複雑さには強い関連がある。 筆者にとって働いてきたのと同様の最初の広大な文字情報のフィードバックを記載する。 表の10-2リストは2つの最も重要なカテゴリだ。
完了パーセントの過程はユーザからのフィードバックを得るために必要なときにベストを選択となる。 それらはユーザがシステムが顧客のリクエストを処理し理想的であるか、待ち時間が長くてキャンセルすることを許可するかを再確認することになる。 最も良いプログレスインジケータはタスクが完了するトータルの時間を見積もり、提供するものだ。 見積もりは注意深く行ったほうが良い、ターキテクトはどれくらい時間がかかるか見積もることは苦手だし、もし見積もりが誤っている場合にい悪い類のフィードバックを選択することになるだろう。
表10-2 フィードバックメカニズム フィードバック | 例
すぐにタスクは1-2秒で完了します。 共通のオブジェクトでビジュアルの変更をする、それはバックグランドで新規メールのダウンロードをメールクライアントが検知しメールが到着したアイコンに変更する 厳密なレスポンスとして、ビープでメッセージを伝えたり、ステータスバーで表示を変更したりする。
継続 タスクは2秒以上かかります。 一般的なアニメーションはループでタスクに時間がかかっているどれくらいの長さを知ることができないこのようなスピングローブはMicrosoftのIEでみることができる。
パーセント表示のプログレスインジケータはタスクの完了を見つもつことができる。 これらはステータスバーに表示されるか、分離したダイアログになっていたりする。