Web アプリケーションのパフォーマンス ベンチマークに関する推奨事項

Question

イントラネット Web アプリケーションのテストを開始しようとしています。具体的には、アプリケーションのパフォーマンスを判断する必要があります。

アプリケーションのパフォーマンスを判断する方法について、誰かが公式/非公式の基準を提案していただけますか。

Answer 1

ストレスと負荷のテストには何らかのツールを使用してください。Java を使用している場合は、こちらをご覧ください Jメーター. 。アプリケーションのパフォーマンスをテストするためのさまざまな方法が提供されます。以下に焦点を当てる必要があります。

• 反応時間:通常のリクエストに対するアプリケーションの実行速度。いくつかの読み取り/書き込みユースケースをテストする
• 負荷試験:トラフィックが多いときにアプリケーションがどのように動作するか。このツールは、一定期間内にいくつかのリクエストを送信します (これは適切に構成できます)。
• ストレステスト:アプリケーションは長期間動作できますか?このテストはアプリケーションを限界まで引き上げます

興味があれば、これから始めてください。他の種類のテストもあります。

Answer 2

フロントエンドをテストする場合、YSlow は、ユーザーの観点からページの読み込みにかかる時間の統計を取得するのに最適です。これは、特定の HTTP リクエストごとの統計、所要時間などに分類されます。で入手してください http://developer.yahoo.com/yslow/

もちろん Firebug も必須です。JS のプロファイルを明示的に、またはプロファイル ボタンを押してリアルタイムでプロファイルできます。必要に応じて最適化を行い、すべての関数の実行にかかる時間を確認します。これにより、JS コードのパフォーマンスを測定する方法が変わりました。 http://getfirebug.com/js.html

Answer 3

本当に重要なのは応答時間だと思いますが、私が注目する他の指標は、プロセッサーとメモリーの使用量とメモリ使用量です。同時ユーザー/プロセスの数。また、通常負荷とピーク負荷の下ですべてが期待どおりに動作しているかどうかも確認します。さまざまなリクエストが互いにステップし合うため、負荷が高くなるとアプリケーション エラーが発生するシナリオが発生する可能性があります。

本当に詳細な情報を取得したい場合は、さまざまな種類の負荷/ストレス テストを実行する必要があります。おそらく、ステップ負荷テスト (時間の経過とともにシステム上のユーザーが徐々に増加する) とスパイク テスト (以前はほとんど誰もアクセスしていなかった場所に、多数のユーザーが同時にアクセスする) を確認するとよいでしょう。また、サーバーの再起動直後にテストを実行して、それがシステムにどのような影響を与えるかを確認します。

また、HEAT (敵対環境アプリケーション テスト) と呼ばれる概念も検討することをお勧めします。実際、これはシステムの一部がオフラインになったときに何が起こるかを示しています。システムは正常に機能低下しますか?これは重要な標準となるはずです。

私の 1 つの大きな提案は、テストを行う前にシステムが何をすべきかを確立することです。主な理由は説明責任です。システムが何かを行うはずであることを人々に認めさせ、それが真実かどうかをテストしてもらいます。これは重要です。人々はすぐに結果を確認し、それが許容されるものに対する基本ベンチマークとなるからです。

Answer 4

「具体的には、アプリケーションのパフォーマンスを判断する必要があります...」

これは、合理的かつ効果的であると考えられるものに対するユーザー コミュニティの期待を捉える要件の問題に一巡します。要件には多数のコンポーネントが含まれます

1. 一般的な応答時間、「負荷がかかっているとき...」サイトの一般的な応答時間は x、y% 未満である必要があります...」
2. 特定の応答時間、「...の負荷の下で」クレジット カードの処理にかかる時間は z 秒未満、時間の a% です...」
3. システム容量の項目、「負荷がかかっています...」CPU|ネットワーク|RAM|DISK は容量の n% を超えてはなりません....」
4. 負荷プロファイル。ユーザー数と発生するトランザクションの組み合わせであり、システム パフォーマンスを決定するために特定の客観的な測定値が収集されます。

応答時間やその他の尺度は絶対的なものではないことがわかります。シックス シグマの製造原則を 1 ページめくると、100 万分の 1 の例外から 10 億分の 1 の例外に移行するコストは桁外れであり、例外をゼロに移行するコストは通常​​、平均的な組織では耐えられないコストです。組織固有のアプリケーションの許容可能な応答時間は、パブリック インターネットに接続されたアプリケーションである高度にコモディティ化された製品とはまったく異なる可能性があります。競争力の高いソリューションの場合、インターネット上の応答時間の期待値は 2 ～ 3 秒の範囲に向かう傾向にあり、ユーザーの放棄が著しく増加します。これは過去 10 年間で 8 秒から 4 秒に低下し、現在は 2 ～ 3 秒の範囲になっています。Facebook などの一部のアプリケーションは、競争上の理由から、1 秒未満のほとんど知覚できないほどの応答時間を記録します。厳密な基準を探しているなら、それは存在しません。

理解に役立つのは、スタイル、形式、機能に関する業界のベンチマークをいくつか読んでみることです。

• TPC-C データベース ベンチマーク ドキュメント
• SpecWeb2009 ベンチマーク設計ドキュメント

ニーズを反映する一連の堅牢なパフォーマンス テストを設定することは、簡単なことではありません。QA 作業のこの段階を担当する専門家を雇うこともできます。

ツールを選択するときは、次のことができるものを選択してください。

• インターフェースを練習する
• 要件に反するレポートを作成する
• あなたまたはあなたのチームが活用できるスキルを持っています
• でトレーニングを受けることができ、経営陣の祝福を受けて参加できます

上記の 4 つの要素のいずれかに不備があると、市場で最も高価なツールを購入し、それを導入するために最も高価な会社を雇ったことになります。

幸運を！