先日尋ねられたトリッキーな質問です... 私たちは、MySQL データベースといくつかのオープン ソース コンポーネントを使用して、C++ と PHP のコードが混在するかなり複雑なテレフォニー (SIP) アプリケーションに取り組んでいます。
通信エンジニアから、アプリケーションのパフォーマンスを見積もるように依頼されました (まだ準備ができていません)。彼は、「1 秒あたりに Linux カーネルを通過できるパケットの数を知っているでしょう。それに加えて、アプリの速度も知っているかもしれません。それで、1 秒あたり何回の呼び出しがあなたのものを通過するか教えてください」と言いました。
何百万ものシナリオが発生する可能性があるため、私にはナンセンスに思えます (まあ、文字通り...)
しかし...実際のテストの前に、アプリケーションのパフォーマンスを見積もる方法はありますか (それが実行されるハードウェアを知っている、その上で標準的なベンチマークを実行できるなど)。
確かに、上限 (最大スループット) 制限で問題を制限できます。それについてナンセンスなことは何もありません。実際、そのようなことを知らないということは、特に電話の世界では、問題へのかなりでたらめなアプローチを示しています。
この問題は自分で解決できます。トランザクションまたはアプリ内のタスク単位で達成しなければならない最小の「作業」は何ですか?
たとえば、いくつかのメッセージのやり取り、いくつかの処理、およびデータベースのヒット? 個々の部分に関する情報を取得すると、最速のスループットを知ることができます。システムに負荷をかけ、パフォーマンスが大幅に低下した場合は、時間を取って、非効率的なアルゴリズムなどでスループットが失われている可能性がある場所を特定できます。
編集
この演習を行うには、各ユース ケースでアプリが実行するすべての手順を理解する必要があります。次に、各ユース ケースの最大スループットを特定できます。リリースしてライブに移行する前に、このことを確実に知っておく必要があります。
あなたが指摘するように、最悪のケースの分析はかなり難しいので無視しています。
Web パフォーマンスのキャパシティ プランニング: メトリック、モデル、およびメソッド を参照してください。この種の離散イベント シミュレーションを実行できるツールもいくつかあります。
これは簡単なことではなく、商用ツールには費用がかかります。キャパシティ プランニング ブックには、すぐに開始できる多数の Excel ワークブック テンプレートとモデルの例を含む CD が付属しています。
幸運を ：）
本当にこれに答える必要がある場合は、次のように言えます。
「頭ではわかりません。あなたのためにこれを見積もるつもりですが、時間がかかります。明らかに、私の答えの正確さは、見積もりを計算するのにどれだけの労力 (IE 時間) をかけたかによって異なります。どのように見積もりの計算にどれくらいの時間を費やす必要がありますか?」
彼らに負担を戻してください。本当に正確な回答が必要な場合は、実際の環境をシミュレートできるテスト アプリケーションを少なくともいくつか作成できるようにする必要があります。
見積もりをするべきです。見積もりでは正しい答えは得られません。しかし、それはあなたに問題について考えさせます。今のところ、あなたのコーディングのように聞こえ、すべてがうまくいくことを望んでいます。または、パニックに陥っていて、見積もりをする時間がないと感じています。
しばらく考えてみてください。重要なユース ケースを分析します。必要なメモリについて考えてください。データベースへのアクセスについて考えてみましょう。ネットワーク アクセス (ローカルおよびリモート) について考えます。これらはシステムのパフォーマンスに影響します。これを行うためにチーム全体をまとめます。
これらの重要なユース ケースの開発中に、システムのパフォーマンスを定期的に測定します。必要に応じて、コンポーネント/その他のシステムをモックアップします。結果を分析します。これらはあなたの見積もりとどのように比較されますか。コンポーネントがメモリ/データベース/ネットワークにバインドされている可能性があります。より多くのメモリが必要な場合があります。データベースへのアクセスが少ない。より簡単なクエリ; キャッシング。これらの変更をすぐに行う必要はありません。ただし、システムがどのように動作し、何をする必要があるかはわかっています。
結果:システム テストでの不意打ちが減りました。リリース日が迫っているので、パニックが減ります。
事前にキャパシティ プランニングを行うことは間違いありませんが、見積もりの質は利用可能なデータの質によって異なります。
最善の見積もりは、テストでシステムを構築し、シミュレートされたワークロードを実行してから、パフォーマンス要件とワークロードの関数として容量を予測することです。これら 3 つは予測空間を形成します - 3 つのうちの 2 つが与えられると、3 つ目を予測できます。
パフォーマンス要件とキャパシティ (ハードウェアなど) が与えられると、処理できるワークロードを計算できます。
パフォーマンス要件とワークロードを考慮して、必要な容量 (ハードウェアなど) を計算できます。
ワークロードとキャパシティを考慮して、期待されるパフォーマンスを予測できます。
パフォーマンスを測定するためにスパイクできます。システム全体はまだ機能していないかもしれませんが、パーツがどのように組み合わされるかはわかっています。最終的なアプリと同じ種類の作業をすべてのレイヤーにわたって行うものを数時間で作成し、それを使用して設計のパフォーマンスを測定できます。
覚えておいてください:プロトタイプは広く、スパイクは深いです。
これは一部のドメインでは当てはまりますが、そのドメインの専門家でない限り、何もわかりません。たとえば、産業用ロボットを制御するためのコードを書きます。速度は、コードの実行速度ではなく、ロボットの動きによって制限されます。ロボットの速度と移動距離がわかれば、「速度」をかなり正確に見積もることができます。あなたのアプリケーションの時間を見積もる方法がわかりません。