15

私の組織は現在、興味深い内部討論を行っており、コミュニティ全体に公開したい質問を提起しています.

当面の問題は、ストレス テスト、キャパシティ テスト、パフォーマンス回帰テストなどを行う環境です。

議論の一方の側には、結果をできるだけ意味のあるものにするために、この環境を本番環境に可能な限り反映させたいと考えているソフトウェア エンジニアもいます。現在、そのようなテスト用の環境はありますが、本番システムよりもはるかに能力が低く、これらのソフトウェア エンジニアは、そこから学べることの限界に達していると感じています。

議論の反対側には、環境を管理し、財布のひもを制御するネットワーク エンジニアもいます。彼らは、本番環境のより優れたレプリカである環境での容量テストがより優れていることを認めていますが、ストレステストの目的のために、より控えめな環境はパフォーマンスのボトルネックを拡大し、それらをより簡単にする効果があると主張しています.発見して修正します。

これは最終的に私の興味をそそる部分に私たちを連れて行きます: あるソフトウェアエンジニアは、より適度なストレス環境は何らかのボトルネックに遭遇する可能性を高めるが、必ずしも次のボトルネックを見つけるのに役立つとは限らないことを示唆しています.制作中の出会い。スケーリング効果は線形ではない可能性があると彼は主張します。

その観点にメリットはありますか？はいの場合、なぜですか？その非線形性の原因は何ですか?

ここには、Java アプリケーション サーバーのクラスター、データベース サーバーのクラスター、HTTP ヒットごとに生成される多数の動的コンテンツなど、多くの可動部分が関係しています。

編集：これまでの皆さんの考えに感謝していますが、誰かがどちらか一方を再確認し、実際に「なぜ」という問題に取り組む以上のことをしてくれることを本当に望んでいました. そのような非線形性があるとすれば、それは何によって生じるのでしょうか? CPU、メモリ、帯域幅、遅延、サブシステム間の相互作用などの観点から理由が表現されていればなお良いでしょう。他の誰もステップアップしない場合は、報奨金の回答としてコメントを再投稿する必要があります

4

6 に答える 6

7

あなたのソフトウェア開発者は正しいです。私はさらにその点を取り上げます。

Web サービスなどのアプリケーション コンポーネントをテストして、負荷がかかった状態での動作を確認する場合、能力の低い環境を使用することは理解できます。メモリや io などに関するボトルネックを見つけることができます。また、ほとんどの場合、メモリ不足エラーやログ ファイルの巨大化などのバグや見落としを見つけることができます。

しかし、アプリケーション コンポーネントが意図したとおりに動作していて、シバン全体をテストする必要がある場合は、実際の環境をテストする必要があります。

環境でストレス テストを実行するときは、負荷がかかっている環境の動作とそのボトルネックを測定します。このテストは貴重な情報を提供する場合がありますが、この情報は本番システムに関するものではありません。見つけたボトルネックは実際のシステムには関係なく、存在しないバグを修正するために貴重な開発時間を費やしている可能性があります。実際に直面する可能性のあるボトルネックを知るには、実際の運用システムでストレス テストを実行する必要があります (できればグランド オープンの前に)。

于 2012-10-23T13:35:43.590 に答える
5

実稼働環境でも同様の状況に遭遇しました。私たちは、初期および基本レベルのテストと調査結果のためだけに控えめなシステムを使用しています。テスト環境で実際のボトルネックやその他のパフォーマンスの問題を見つけることは決してできないのは事実です。したがって、実際のパフォーマンス関連の問題を見つけ、ボトルネックを見つけるには、実稼働環境でそれを実行する必要があります。他に方法はありません。

250万を超えるWebサイトをホストしていますが、あなたの場合はそうではないかもしれませんが、私たちの場合、線形のボトルネックという恐ろしい状況に直面していることをお伝えしておきます。つまり、トラフィックが増加しているときに、最初にメモリの問題に直面しました。メモリを追加することでこれを解決しました。それまでは、メモリが限られているため、httpdのスレッドが256個しかないことが次のボトルネックであることに気づいていませんでした。メモリの問題を解決すると、ウェブサーバーが数週間後に再び遅くなるという問題がすぐに発生しました。256個のhttpdスレッドでは、それほど多くのトラフィックを処理するには不十分であることがわかりました。この問題を軽減するために、スレッドを増やすだけでなく、Webサーバーの前にHA並列ロードバランサーをインストールしました。

幸い、ページの読み込みが遅いという問題は解決しました。しかし、トラフィックが継続的に増加する数か月後、ストレージシステムの次のボトルネックに陥りました。今回のディスクI/Oの問題はご存知でしょう。話を短くするために、並列NFSベースの物理ストレージシステムを配置します。各NFSマシンは、2000を超えるスレッドを実行することでファイルを提供するようになりました。

データベースも低速の大きな原因であり、マスタースレーブモデルをクラスターにインストールすることでその問題を解決したことを忘れました。アプリケーションコードでも多くのパフォーマンス調整を行う必要があり、アプリケーションをさまざまなサーバー上のさまざまなモジュールに物理的に分散させる必要がありました。

パフォーマンスに関連するすべての問題がほぼ直線的に発生する可能性が非常に高いことを証明するために、これらすべてに言及しているだけです。少なくとも、Webベースのモデルで直面していることです。控えめなシステムで多くのテストを行ったとしても、テスト環境では見つけることができない隠れたボトルネックが発生する可能性があります。

過去6年間の経験で私が学んだことは、大量のトラフィックまたは1秒あたりのヒット数が発生する可能性があると思われる場合に、モデルを可能な限り分散させようとすることです。一元化されたモデルは、多くの調整を行うことでトラフィックをしばらく保持できますが、最終的にはシステムが破壊されます。

私はあなたがあなたの状況でいくつかのボトルネックや問題に直面すると言っているのではありませんが、私はあなたがよりよく知っているように、これらのケースが時々起こることを警告したかっただけです。

**英語でごめんなさい。

于 2012-10-31T16:27:34.723 に答える
5

ネットワーク エンジニアは、控えめなシステムは基本的に実稼働システムの縮尺モデルであると想定しています。彼らはまた、ソフトウェアのパフォーマンスに影響を与える実稼働環境のさまざまな特性が、より控えめなシステムに反映されていることを前提としていますが、その比率は同じです。たとえば、CPU がそれほど速くない、メモリがそれほど多くない、ストレージが少し遅いなど、これらすべての違いは同様の比率であり、すべてが魔法のように何らかの係数、たとえば 1.77 で乗算された場合、その結果、変更された控えめなシステムは、実稼働システムとまったく同じになります。

しかし、控えめなシステムが生産システムのすべての詳細において正確な縮尺モデルであるとは信じがたいです。

これが具体的な例です。本番システムでの測定結果が、CPU 使用率 (CPU がアイドル状態ではない時間の割合) が高すぎることを示しているとします。したがって、ソフトウェアを中程度のシステムに配置して測定を行い、中程度のシステムでは CPU 使用率が低いことを発見します。調査の結果、中程度のシステムではストレージが低速であり、CPU がストレージからのデータ転送の完了を待機するアイドル状態により多くの時間を費やしていることが明らかになりました。これは、中程度のシステムではアプリケーションが I/O バウンドであるのに対し、運用システムではそうではないためです。この違いは、CPU 比率が I/O 転送比率とは異なるため、控えめなマシンが本番マシンの正確な縮尺モデルではないことに起因します。

もう 1 つの例は、より多くのメモリを使用して、運用環境でのページ フォールトを少なくすることです。ソフトウェアがより控えめなマシンにロードされると、物理メモリが少ないため、ページ フォールトが多くなります。さまざまなアプリケーションがページインおよびページアウトすると、他のアプリケーションのページがスワップアウトされ、再びスワップインされるため、相互に影響を及ぼし始めます。より大きなメモリを搭載した製品マシンでは、より多くのアプリケーションを同時に保持するのに十分なメモリがあるため、このカスケード ページ フォールトの動作は見られません。

ここで本当に言いたいことは、さまざまなパーツとアプリケーションをすべて備えたコンピューターは、複雑で動的なシステムであるということです。あるコンピューティング環境が別のコンピューティング環境の単なる縮尺モデルであるという考えは、単純すぎる仮定です。控えめなシステムを使用すると、確かに貴重なデータが得られます。ただし、ソフトウェアの大まかな調整が行われ、より微妙な詳細な調整が開始されると、環境の違いがテストの結果に大きな影響を与える可能性があります。

いくつかの引用。 コンピュータ システムは、Tod Mytkowicz、Amer Diwan、Elizabeth Bradley による動的システムです。

Uri Lerner、Ronald Parr、Daphne Koller、および Gautam Biswas による動的システムにおけるベイズ故障検出および診断。

于 2012-10-30T22:51:42.400 に答える
2

私たちはお客様のために毎日テストシステムをロードしています-そして私たちはさまざまな問題を目にしています。特定のクラスの問題は、小型化されたシステムで見られます。他の人はできません。いくつかは本番環境でのみ見つけることができます...2つのシステムをどれだけ厳密にミラーリングしても、それらが同一になることは決してないためです。十分に努力すれば、本当に近づくことができます。

つまり、テストの簡単な事実です。システムが本番システムに近いほど、テストはより正確になります。

IMO、これはクラウドに移行する最も良い理由の1つです。本番システムに非常に近いシステム（これまでに入手できるものとほぼ同じ）を起動して、その上で負荷テストを実行できます。

顧客がテスト環境で、本番環境では発生しなかった問題を追跡するために多くの時間を浪費するのを時折見たことがあることは、おそらく言及する価値があります。環境が異なればなるほど、これが発生する可能性が高くなります:(

于 2012-10-24T15:23:16.160 に答える
2

あなたは自分の質問に部分的に答えたと思います-あなたはすでに本番レベルの環境を持っていて、それが本番環境と同じレベルではない/能力がないことにすでに気づいています。肝心なのは、世界中のすべてのお金で、本番Webサイトの正確な機能を複製することは決してできないということです-イベント、ボリューム、CPU使用率、メモリ使用率、DB IOのタイミング、すべてが怒りの行動で働いているときある程度非決定的である可能性があります。私のポイントは、あなたがそれを完全に同じにすることは決してできないということです。そして、コインの反対側では、その性質上、本番環境は、データ/トランザクションの本番ボリュームを実行および処理するために、多くのキットを備えた高価な環境になります。これはビジネスにとって大きな出費/諸経費であり、

おそらく、別の戦術をとる必要があります-本番ソフトウェアのパフォーマンスプロファイルを学びます-ボリュームに応じてどのようにスケーリングするか、実行時間は直線的、指数関数的、または対数的に増加しますか？これをモデル化できますか？まず、テスト環境が同様に動作していることを確認できます。これは、有効なテストを行うための鍵です。次に、もう1つの重要な部分は、絶対ではなく相対テストを行うことです。本番環境と同じ絶対実行時間を取得することはありませんが、コード変更をデプロイする前にパフォーマンステストを実行してベースラインを取得してから、コードをデプロイします。変更してパフォーマンステストを再実行します-これにより、本番環境での相対的な変更が得られます（たとえば、このコードリリースでパフォーマンスが低下します）。

ですから、私の見解では、低環境でのソフトウェアとハ​​ードウェアのパフォーマンスについて多くのことを学ぶことができます。これを小規模で能力の低いインフラストラクチャで行うと、会社のコストを節約できます。正しく使用すれば、ほとんどの回答が得られます。あなたが探しているパフォーマンステストに。

于 2012-10-26T21:48:43.600 に答える
2

良い質問。学習と最適化は、控えめなハードウェアで行うのが最適です。しかし、テストはミラー（または少なくとも同じエポックからのもの）でより安全です

最初に現れるボトルネックと、それがいつ起こるかを予測しようとしているように見えます。それが正しい目的であり、正しい方法であるかどうかはわかりません。クライアントが「他のすべてのWebアプリケーションと同じくらい速く動作するはずだ」と言う典型的なCRUDについては話さないと思います。テストを正しく実行したい場合は、テストを開始する前に、予想される負荷を知っておく必要があります。予想されるユーザー数、予想されるイベント数、応答時間など。これは製品仕様の一部です。数字がない場合は、アナリストが仕事をしていないことを意味します。

数字があれば、正確なテスト結果は必要ありません。大きさの順序を知る必要があるだけです。また、ソフトウェア/ハードウェアのスケーリング方法も確認する必要があります。x ユーザー/リクエスト/その他を処理するために必要なインスタンスの数と、y を処理するために必要なインスタンスの数

于 2012-10-22T20:24:04.580 に答える