連続クエリをサポートするデータ ストリーミング システムのパフォーマンスをテストしています。
これがどのように機能するかです: - システムにデータを送信するポーリング サービスがあります。- データがシステムに渡されると、各クエリは現時点でのストリームのウィンドウに基づいて評価されます。- データが通過すると、ウィンドウがスライドします。
私の問題はこれです。システムにクエリを追加すると、データレートに対応できないため、スループットが低下することが予想されます。
ただし、実際にはスループットの増加が見られます。
なぜそうなのか理解できません.JVMがCPUやメモリなどを割り当てる方法に関係していると推測しています.
誰でも私の問題に光を当てることができますか?
ほとんどの Java 仮想マシンは、最初に JVM バイトコードを解釈しますが、これはネイティブ マシン コードの実行よりもわずかに遅くなります。JVM は、コードの特定のセクションを繰り返し使用していることを検出すると、そのコードのセクションをネイティブ マシン コードにコンパイルします (処理速度が向上します)。その結果、コードのストレス テストを行ったり、コードを長時間実行したままにしたりすると、実行が遅くなるどころか、速度が上がる傾向があります。HotSpot JVM (SUN のデフォルト) は、ネイティブ コンパイルを実行してコード実行を高速化する最もよく知られている JVM です。
また、多くの Java ライブラリは、過去に遭遇した可能性のある一部のライブラリと比較して非常に成熟しています。つまり、リクエストを処理するためにスレッドを割り当てる代わりに、ソケットのノンブロッキング リスナー、再割り当て可能なワーカー スレッドのスレッド プール、または高スループット処理に適した任意の数の手法を使用している可能性があります。これは、JIT (HotSpot のような) JVM の自己調整と相まって、Java のベンチマークを非常に困難なものにします。一般的に言えば、ある程度までは、実行時間が長くなるほど速度が速くなる傾向があります。
いつものように、答えはプロファイルすることです。推測ですが、Hotspot VM は JIT マジックを実行し始める前にかなりの数のパスを必要とします。
あなたの質問は技術的な詳細に非常に軽いですが、ここに推測があります。
IO ストリーミング サブシステムが適度に効率的 (selectベースなど) で、個々のクライアントがネットワーク インターフェイスを飽和させない場合、サーバー プロセスがより多くのデータを処理できるため、多数のクライアントが存在することで総スループットが増加する可能性があります。
もう 1 つのばかげた理論: もちろん、少なくとも容量に達するまでは、負荷が増加するとスループットが増加します。1 秒あたり平均 100 件のクエリを処理でき、1 秒あたり平均 10 件を送信すると、1 秒あたり 10 件のクエリを処理できます。負荷を平均 100qps に増やすと、スループットは (ほぼ) 100qps になります。もちろん、その後は悪化します。定員に近づいていませんか？これがあなたが確実に除外したものである場合は申し訳ありません。
Java アプリケーションのパフォーマンス、特にマイクロベンチマーク (非常に小さなコード片のベンチマーク) は、Java では非常に難しい場合があります。これは、JVM、JIT コンパイラー、およびガベージ コレクターがプログラムのパフォーマンスに大きな影響を与える可能性があり、予測が難しいためです。 .
Java の並行性とパフォーマンスの第一人者である Brian Goetz による優れた一連の記事「Java の理論と実践」があります。