stress-testing - 開発サーバー/本番サーバーのストレステスト

Question

私はストレステストに非常に慣れておらず、ロープを学ぼうとしているだけです。だから私の質問は：

1. ソフトウェアに関しては同一であるが、ハードウェアに関しては本番サーバーよりもはるかに低いスペックの開発サーバーがある場合、明らかなソフトウェアの欠陥を特定するために開発サーバーをストレステストする価値はありますか？

2. ユーザーのエクスペリエンスを危険にさらすことなく、稼働中の本番サーバーのストレステストを行うのに最適な方法はどれですか。または、稼働中の本番サーバーのテストを強調することは避けてください。

Answer 1

さまざまなヒント/提案を次に示します。

• アプリケーションが新しく、本番環境での負荷を処理できるかどうかわからない場合は、「容量」テストを行う必要があります。本番ハードウェアで容量テストを行う必要があります。これはまだ「稼働」していないため、ユーザーには影響しません。

• アプリケーションがすでに運用環境にデプロイされている既存のアプリケーションである場合は、「パフォーマンス回帰」テストを行う必要があります。

• パフォーマンス回帰テストは、開発サーバー上のすべての個々の「機能」(アプリケーションにとってそれが何を意味するかに関係なく) のストレス テストを実行して、そのパフォーマンスを測定することで構成されます。結果を「ベースライン」として記録します。

• アプリケーションに変更を加えたら、パフォーマンス回帰テストを再実行して、結果がベースラインから大幅に変化したかどうかを確認します (新しい数値を新しいベースラインとして記録します)。

• 開発サーバーでのパフォーマンス低下の結果がベースラインからあまり変化しなかった場合、サーバーの使用率が変化する (つまり、過負荷になる) ことなく、安全に本番環境にデプロイできるはずです。

Answer 2

テスト環境で再現できない問題があることがわかっている場合を除き、運用マシンでのストレス テストを含む作業は避けるべきだと思います。テストが非侵入/読み取り専用である場合、それは追加のオプションだと思います。

弱いマシンでの分析パフォーマンスに関しては、それほど悪くはありません。ほとんどのボトルネックは、システムの不適切なアーキテクチャが原因であり、さまざまな負荷シナリオで、さまざまなハードウェア構成で表示されるはずです。開発システムでストレステストと最適化を行うと、少なくとも理論的には本番システムがさらに優れているはずであることがわかります。