複数のスレッド (プロデューサー) が単一の ConcurrentHashMap に書き込むアプリケーションの一部をベンチマークする方法がわかりません。さらに、特定のサイズに達すると、1 つのコンシューマー スレッドがマップを空のマップに切り替えます。プロデューサー スレッドは、追加の輻輳なしでできるだけ速くマップに書き込む必要があるため、マップの切り替えが必要です。コンシューマ スレッドは、マップの要素も処理し、バッファに格納します。最後に、別のスレッドがバッファーの内容をアプリケーションの他のコンポーネントに送信します。
要素が送信される準備が整うまで (-> 集約されたスループット)、要素が ConcurrentHashMap に書き込まれるのにかかる時間 (および対応するスループット) を測定する方法は不明です。今のところ、物事を簡単にするために要素の送信を除外しています。マップ サイズによってスループットが抑制されることがわかっています。ただし、将来の実装のスループットと比較するために測定したいと考えています。
これまでに、次のシナリオを調査しました。
サイロ テスト
このベンチマークは、1 つのベンチマーク内の各ステップを測定します。ベンチマーク A: サイズ (= batchSize) に達するまで要素を Map に挿入します。ベンチマーク B: 要素がバッファに格納されるのにかかる時間を測定します。
利点: 比較的簡単に実現できます。
欠点: ベンチマーク A と B を加算すると、スレッドの対話性が失われ、スループットの集計が得られない。
Flat-Test
Silo-Test と比較して、すべてのステップが 1 つのベンチマーク (シングル スレッド) 内で実行されます。最初に X 要素が Map に挿入され、次に Map が切り替えられ、X 要素が処理されてバッファに格納されます。
利点: 比較的簡単に実現できます。
欠点: スレッドの対話性が失われ、ベンチマークは 1 つのスレッド (-> 1 つのプロデューサーのみ) でしか実行できません。現在の実装では、マップの切り替えと要素の同時処理がサポートされていないためです。
Dynamic-Amount-Test (優先テスト)
ベンチマーク メソッドは、呼び出しごとに 1 つの要素をマップに挿入します。コンシューマー スレッドは @Setup フェーズで開始され、テスト中に要素をバッファーに配信します。ベンチマークの最後に、ベンチマーク メソッドの呼び出しを使用する代わりに、バッファ内の収集された要素の数が結果計算のために JMH に提供されます。ベンチマークの最後にバッファ サイズを JMH に提供できる、すぐに使用できる機能については認識していません。ほとんどの場合、この要件のために JMH を変更する必要があります (そうですか?)。
利点: 合成スループットは JMH によって計算されます
欠点: すぐに使える機能はありません。JMH の変更は危険な場合があります (測定に影響があり、ベンチマークの有効性が不明です)。
補足事項: このシナリオでは、非定常状態のベンチマークにも対処する必要があります。JMH のバッチ処理の可能性を利用して、さまざまなサイズでテストすることを考えました。
建設的な回答をお寄せいただきありがとうございます。