ベンチマークは、1000の同時リクエスト

Question

上のLinux/Apacheのパフォーマンスのために、私は次のような構成のLinuxサーバがあります。私は500の並行スレッドでJ-メートルでテストをしています

Architecture:   x86_64 
CPU op-mode(s):  32-bit, 64-bit 
Byte Order:   Little Endian 
CPU(s):    1 
On-line CPU(s) list: 0 
Thread(s) per core: 1 
Core(s) per socket: 1 
Socket(s):    1 
NUMA node(s):   1 
Vendor ID:    GenuineIntel 
CPU family:   6 
Model:     62 
Model name:   Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz 
Stepping:    4 
CPU MHz:    2500.046 
BogoMIPS:    5000.09 
Hypervisor vendor:  Xen 
Virtualization type: full 
L1d cache:    32K 
L1i cache:    32K 
L2 cache:    256K 
L3 cache:    25600K 
NUMA node0 CPU(s):  0 

RAM = 2 GB 

をし、10秒の期間を立ち上げます。私は3 /秒のスループットを得る。どのようにこのスループットが良いか悪いか分かりますか？結果を比較できるベンチマークがありますか？スループットと偏差。

Answer 1

「良い」または「悪い」スループット自体はありません。アプリケーションの目標とステークホルダーの期待に応じて、3 /秒のスループットは完璧または恐ろしいものになります。だから最初の質問はあなたのパフォーマンスの目標は何ですか？あなたは、グラフではなく、単一のポイントを持っているとき

第二に、スループットについて結論はのみ到達することができます。

あなたが「成長」または「プラトー」段階にある場合、そのユーザーの下限と高い数字でポイントを持たずに、あなたが本当に知らない：スループットのための典型的なグラフは次のようになります。また、スループットのグラフは次のようになります。

ので、それは高原に、成長または悪化している場合は、また、知らないだけで1点を有します。

最後に、ユーザー数はスループットに影響するパラメータの1つに過ぎません。他には含まれる：要求のタイプ、データのサイズ、テストの時間（例えば長いテストが短いテストに増加または不可視分解するためにスループットの傾向を示してもよい）、など

だから私の提案は次のようになります。

を

• アプリケーションの目的が何であるかを関係者に確認してください。たとえば、開発者はスループットがどのようなものか期待しています。

• 操作の点で実績のあるベンチマークを確立します。 「ユーザーの過半数」を表すもの。テストでスループットが大幅に変更される可能性のある操作が考慮されていることを確認してください。

• 、テストを変更せず（それが24時間であるかもしれない他の人のために、それは10分であることができ、いくつかのアプリケーションのために、）安定したスループットを表示する可能性がありますテストの期間中、

• を確立することが、複数の実行（例えば、100,200,300、...）を増やしてグラフを得ることができる。アプリケーションが破損するか、パフォーマンスが許容できないほど低下するまでユーザーの数を増やし続けます。 3 /秒のスループットは、あなたのアプリができる最善である、またはそれははるかに良い行うことができればあなたの全体像との良好な理解を得られます

。そして、あなたのアプリができる最高のものがあなたのステークホルダーのために十分であるかどうか。

2番目の画像はthis pageから取得されました。