アプリケーションのストレス テストまたは負荷テストの頻度に関するルールはありますか? 私は通常、新しいバージョンを本番環境に投入する前、ハードウェアが変更されたとき、または予想されるユーザー数が変更されることがわかっているときに行います。
しかし、今日、変更が導入されていなくても、これが実稼働中のアプリケーションの標準的な方法であるべきかどうか尋ねられました。もしそうなら、どのくらいの頻度ですか？
1530 次
10 に答える
6
それは本当にあなたがあなたの会社のニーズのためにそれにどのように対処したいかに依存します。個人的には、ビルドが終了するのと同じように、統合（テスト）ビルドを毎日負荷テストします。ビルドが約1aで実行された後、負荷テストも行うようにスクリプトを作成します。私たちの目標は、パフォーマンスのビルドオーバービルドの変更を具体的に探すことです。コードに変更を加えなくても、コードの負荷テストが行われるサーバーは、更新/パッチ/ホットフィックス/サービスパックなどを受信します。最悪の場合、自動化されると、追加の履歴データが提供されます。
本番環境でハードウェア環境を複製しようとすると法外なコストがかかるため、このルート（相対性理論の構築）を使用します。主要なパフォーマンスモニターに突然の変更（または段階的な変更）が見られた場合は、その時点で導入された変更セットを調べて、パフォーマンスに悪影響を及ぼした潜在的なコード変更を特定できます。
その音から、本番環境を複製するラボに対してテストしていますか？これは、私たちが持っていたのとは異なるアプローチです。なぜなら、ボトルネックのほとんどはコードによって引き起こされ、ハードウェアに直接依存しないという仮定の下にあるからです。VMを使用して、本番環境を概算しますが、複製はしません。
于 2009-10-26T19:06:46.853 に答える
3
コードが変更されていなくても、システム パフォーマンスに影響を与えるものの 1 つはデータです。
例としては、データベース クエリのパフォーマンスがあります。データがテーブルに追加されると、インデックスを維持するコストが増加します。インデックス内のページ分割により、パフォーマンスが低下する可能性があります。インデックスが大きくなるにつれて、インデックスの「レベル」の数を頻繁に増やす必要があります。それが起こると、明らかに不可解なパフォーマンスの突然の変化が見られます。
本番環境でストレス テストを実行できるとは限りません。日常業務に影響を与えます。多くの場合、システムはパフォーマンスに関する継続的なフィードバックを提供するように装備されています。神経節のようなものを使っているのかもしれません。データは、問題の検出とキャパシティ プランニングに使用されます。
于 2009-10-26T21:51:39.113 に答える
1
コード、データ ファイル、ユースケースなど、アプリケーションで何かを変更するときはいつでも、予想されるユーザー数を含むがそれに限定されない場合は、それをテストする必要があると思います。
于 2009-10-26T19:03:56.983 に答える
1
私の 2 セント: 何も変更しないと、サイトのパフォーマンスが低下する場合があります。あまりにも多くのデータを処理するアプリが原因である可能性があります (例: キャッシュのオーバーフロー)。サイトのサードパーティの広告がスローダウンしている可能性があります。一体、それは RAM の障害が原因である可能性があります。
主なことは、既知の変更後にテストを行うことを一般的にお勧めしますが、パフォーマンスに影響を与える可能性のある未知の変更を確認するために、時々パフォーマンス テストを行うことも悪い考えではありません。
私の会社、BrowserMob は、サイトに対して X 分ごとに実際の Selenium スクリプトを実行する無料の Web サイト監視サービスを提供しています。これは負荷テストではありませんが、運用サイトの傾向とボトルネックを特定するのに役立ちます。
于 2009-11-16T18:14:31.260 に答える
0
製品に変更が導入されておらず、負荷テストで同じプロセスが一定の間隔で繰り返されるだけの場合、再実行のメリットはわかりません。
于 2009-10-26T19:06:27.400 に答える
0
以前はantファイルの一部としてストレステストを行っていたので、必要に応じて毎晩それらのテストを実行でき、変更を加えたり、新しい変更の可能性をテストしたりするときに実行しました。または、改善があったかどうかを確認するために、私がテストしていたものに別の影響を与えます。
どのくらいの頻度であなたの環境に依存すると思います。
開発中のテストに本当にストレスをかけることができない場合は、本番環境に移行する直前にテストを行っているQAに到達するまで待たなければならない場合があります。
2泊前に動作したことがわかっているので、問題を見つけて修正するのが早いので、早ければ早いほど良いと思います。昨夜はテストに失敗したため、日中に何らかの変更が発生しました。
私はストレステストの多くにjunitperfを使用しました。
于 2009-10-26T19:10:53.663 に答える
0
テストに必要な労力によって異なります。それが十分に簡単であれば、より多くのテストを行っても問題はありません。ただし、変更が予想されないかどうかをテストする理由はありません。これにより、ソフトウェアが長期間テストされないことにつながる場合は、予期しない変更があった場合に備えて、時々テストを実行することが適切な場合があります。
言うまでもなく、ソフトウェアが原子炉または掲示板を実行しているかどうかにも依存します。
于 2009-10-26T19:04:37.060 に答える
0
メモ帳のストレス テストはしたくないと思います。それは冗談だ。気にしないでください=）。
すべてのアプリケーションに対するストレス テストではありません。:-)
于 2009-10-26T19:19:38.870 に答える
0
これは、システムがどれだけミッションクリティカルであるかによって異なります...それが、本番環境に配置した後、それがなくてもできる単なる小さなツールである場合。あなたの人生がそれに依存しているなら、すべてのビルドの後。
私に関する限り、そうです。
于 2009-10-26T19:03:27.577 に答える
0
あなたのソフトウェアが誰かを殺すことができるなら、そうすべきだと思います。
システムのタイムアウトにより血液が届かず、誰かが死ぬことを想像してみてください。
"Timeout.exception: あなたの心はもう来ていません。後でもう一度やり直してください"
于 2009-10-26T19:46:05.637 に答える