21

Javaの架空のHFTシステムを想像してみてください。これには、(非常に)低レイテンシが必要であり、不変性(Scala?)が原因で短命の小さなオブジェクトがたくさんあり、1秒あたり数千の接続があり、メッセージの数がわいせつに渡されます。イベント駆動型アーキテクチャ(akkaとamqp?)。

そこにいる専門家にとって、JVM 7の最適なチューニングは(仮想的に)何でしょうか?どのような種類のコードがそれを幸せにするでしょうか?ScalaとAkkaはこの種のシステムに対応できるでしょうか?

注:これと同様の質問がいくつかありますが、Scala(JVMに独自のフットプリントがあります)をカバーする質問はまだ見つかりません。

4

3 に答える 3

37

Javaで非常に優れたパフォーマンスを実現することは可能です。ただし、信頼できる回答を提供するには、質問をより具体的にする必要があります。レイテンシーの主な原因は、以下の非網羅的なリストから得られます。

  1. 作成するゴミの量と、それを収集して宣伝するためのGCの作業。私の経験では、不変の設計は低レイテンシーにはうまく適合しません。GCチューニングは大きな焦点である必要があります。

  2. JVMをウォームアップして、クラスがロードされ、JITがその作業を実行できるようにします。

  3. アルゴリズムをO(1)または少なくともO(log2 n)になるように設計し、これを主張するパフォーマンステストを行います。

  4. デザインはロックフリーであり、「シングルライターの原則」に従う必要があります。

  5. スタック全体を理解し、その使用に機械的な共感を示すことに多大な努力を払う必要があります。

  6. キャッシュに適したアルゴリズムとデータ構造を設計します。最近のキャッシュミスは最大のコストです。これはプロセスの親和性と密接に関連しており、正しく設定されていないと、キャッシュが大幅に汚染される可能性があります。これには、OSや、場合によってはJNIコードへの共感が含まれます。

  7. 実行する必要のあるスレッドが待機せずにコアを使用できるように、十分なコアがあることを確認してください。

私は最近、そのような演習のケーススタディについてブログを書きました。

于 2012-04-04T11:28:20.607 に答える
26

私のラップトップでは、Akka 2.3.7アクター間のpingメッセージの平均遅延は約300nsであり、JVMでのGCの一時停止が原因で予想される遅延よりもはるかに短くなっています。

Intel Core i7-2640MでのAkkaおよびその他のアクターのコード(JVMオプションを含む)とテスト結果はこちら

PS DmitryVyukovのサイトとMartinThompsonのブログで、低遅延コンピューティングの多くの原則とヒントを見つけることができます。

于 2012-04-01T10:37:26.153 に答える
11

メッセージパッシングにリングバッファを使用すると、Akkaで実行できるものを超える場合があります。人々が金融アプリケーションのためにJVMで使用する主なリングバッファの実装は、効率(2サイズのパワー)、JVM(GCなし、ロックなし)、および最新のCPU(偽共有なし)のために注意深く調整されたDisruptorと呼ばれるものです。キャッシュライン)。

これはScalaの観点からの紹介プレゼンテーションですhttp://scala-phase.org/talks/jamie-allen-sdisruptor/index.html#1そして最後のスライドに元のLMAXのものへのリンクがあります。

于 2012-07-03T03:52:04.447 に答える