問題タブ [low-latency]

Java で C# クラスを複製しています。(私は Java の初心者です。)

私のクラスは、double に関連付けられた int 値を追跡する必要があります。次に、値が double を下回ったり上回ったりするたびに、Alerter(int) を作成する必要があります。

Alerter.LatencySensitiveAction() は、すぐに呼び出す必要があります。これは、遅延の影響を受けやすく、タイム クリティカルなコードです。DoubleMap クラスの目的は、LatencySensitiveAction() をできるだけ速く呼び出すことです。

DoubleMap.OnData() は、クラスの遅延に影響されやすいメソッドです (以下)。

TreeMap は理にかなっていますか? C# で SortedList を使用しています。キーと値のペアを高速トラバーサルでソートされた順序で格納する連想コレクションを探しています。

私はこのJavaコードと言われました

新しいオブジェクトを作成するため、効率的ではありません。代わりに何を使用すればよいですか?

したがって、基本的に、double と int を関連付けることができ、ソートされた順序で格納され、コレクションを順番にトラバースする最速の方法を使用するコレクションを尋ねています。

私の C# コード (以下) でうまくいくと思いますが、Java への変換には助けが必要です。私の C# コードも改善できると思われる場合は、教えてください.. ty.

Java コード:

C# コード:

同じ桟橋コンテナで実行されている2つの戦争の間で低遅延の通信を実現するためにどのようなオプションがありますか？

基本的に、ある戦争で他の戦争からサービスを呼び出す必要がありますが、それをWebサービスとして呼び出すオーバーヘッドを支払う余裕はありません。

それらは同じJVMで実行されているため、RMI / JVMなどの使用を避けたいと思っていますが、他にどのようなオプションがあるのか​​わかりません。

サーブレット間の通信を見てきましたが、メソッドの直接呼び出しは非推奨になっているため、これは正しい選択ではないように思われますか？

kyronetも見つけましたが、これは同じJVMにあるので、より良い解決策はありますか？

私が探しているのは、Apache CamelのVMコンポーネント（ Webアプリケーション間のセダ）のようなものですが、アプリケーションの1つだけがCamelを使用しているため、これはオプションではありません。

戦争の合間にいくつかのDTOを共有する必要があるかもしれないことは知っていますが、サービスを共有ライブラリに取り込むことを提案しないでください。それがオプションである場合は、この質問をしません:)

編集：

EJBコンテナを埋め込むこともおそらくオプションではありません。

Java で JVM によって作成されたスレッドを誰が管理しているのか知りたいですか?

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

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

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

スレッドを 1 ～ 2 マイクロ秒中断する方法はありますか? (注 1 マイクロ秒 = 1/1000 ミリ秒)。この質問が聞かれたことは知っていますが、これまでのところ、これに対する良い答えはありません。これが必要な理由は次のとおりです。

クライアントのリクエストに対応するために複数のスレッドが実行されているサーバーがあります。要求は、時折発生する共有メモリを介して他のスレッドによって送信されます。ただし、リクエストが送信されたら、できるだけ早く処理する必要があります。そのため、リクエストが共有メモリでキューに入れられたときに、処理中のスレッドの 1 つに通知するための高速な方法が必要です。

Windows イベント オブジェクトが使用されましたが、マシンで SetEvent() から WaitForSingleObject() が返されるまでに 6 ～ 7us かかります (プロセス/スレッドの優先順位を設定しようとしましたが、まだあまり改善されていません)。ビジー ループを使用して、サービス スレッドがメモリをプールし続けるようにして、レイテンシを 1 ～ 2us に下げました。マイクロ/ナノ秒のスリープをループに挿入できれば、レイテンシを低く保ちながら、少なくとも CPU を解放できます。

2us 未満のレイテンシでスレッド通信を行う別の方法を誰かが提案してくれたらうれしいです。ありがとう

今後の Windows 8 用のアプリを開発することを検討しています。このアプリでは、低遅延のオーディオ録音と再生が必要であり、OS がそれをサポートするかどうかを調べています (他のプラットフォームとは対照的に)。

だから私が知りたいのは：

1. Windows 8 に低遅延のオーディオ API はありますか?
2. PC 以外のプラットフォーム (タブレットなど) でサポートされますか?

ありがとう！

低レイテンシ Java アプリのパフォーマンスを測定するプロセスは、非低レイテンシ Java アプリのパフォーマンスを測定するプロセスとは異なりますか? はいの場合、その方法は?また、低レイテンシのパフォーマンスを測定するために使用される特定のツールはありますか?

編集: たとえば、ここに具体的な情報があります: http://www.artima.com/forums/flat.jsp?forum=121&thread=212810

AzulSystemsによって構築されたjHiccupツールを使用して「しゃっくり」を測定しています。データを収集して、JVMがJavaアプリケーションを実行している間に発生する一時停止時間（一時的な中断）の頻度と期間を特定します。JVMレベル以降（OS、ドライバーなど）で動作します。

結果は次の とおりです。これらの結果は、SUSE SLERT 112.6.33カーネルPREEMPTRT、Intel i5、4gメモリを搭載したマシンで得られたものです。プロセスは、CPUシールド（3つの論理プロセッサが分離された）および99の優先度（FIFO）で実行されていました。この57mcsのレイテンシーはどこから来ているのだろうか。アプリケーションは非常に簡単です。これはネットワーク注文処理システムであるため、TCPパケットフィードを解析し、単純なビジネスロジックを実行します。GCなし、同期化、シングルスレッドです。

私の推測では、読み取りのブロックなど、ネットワークの問題である可能性がありますか？ビジーウェイトでノンブロッキング読み取りを試したところ、同様の結果が得られましたが、間違っている可能性があります。これらのしゃっくりがどこから来るのか私にはわかりません。

私はjust-pingを使用してGoogleパブリックDNSサーバーにpingを実行します。IPは8.8.8.8です。 just-pingは、世界中の50か所からホストにpingを実行できます。

DNSの遅延は世界中で低いことがわかりました。多くの都市は互いに遠く離れていますが、pingで同じ低遅延（約5ms）が得られました。

IP8.8.8.8は1つのホストに向けられていると思います。そのホストは、クライアントから遠く離れていても、どのように速く反応しますか？

ありがとう！

可変期間の「ビジネス ロジック」タスクがあるプロセスでディスラプターを効果的に使用するにはどうすればよいですか? 以前に行われたことがありますか？

応答ステージを処理する 2 番目のリング バッファーで実行できますか? もしそうなら、どうすればいいですか？

ディスラプターを理解し、コール チェーンの特定の部分に概念を適用できることを確認しました。具体的には、アプリケーションは次の手順を実行するミドルウェア タイプのアプリケーションです。

• 受信メッセージを読み取り、アンマーシャリングしてリクエストする
• リクエストの顧客の詳細を特定し、処理するワークフロー手順を決定します
• バックエンド システムを呼び出してステップを実行する
• 応答を照合し、応答をログに記録し、マーシャリングして、消費者に返す

問題は、バックエンド ステップの一部のインスタンスに「長い」時間がかかる可能性があることです。これにより、実行時間の短いタスクの応答ステージが実行時間の長いタスクを待機する可能性があります。バックエンド システムの呼び出しは、非同期または同期のいずれかで実行できると仮定します。そのため、バックエンド システム コールは、バックエンドへの非同期要求をトリガーする単なるコンシューマーであるという考えになります。

バックエンド システムの応答時間は、5 ミリ秒 (一部の要求)、50 ミリ秒 (要求の 90%) から - 5000 ミリ秒 (要求の 1%) の範囲です (大きなディスク I/O を考えてください)。

ディスラプターは非常に効率的である可能性があると考えていますが、平均レイテンシを低く抑えるためにこのハードルを回避することはできません.