制御クライアントは、さまざまなトピックの拡散を通じて、2 秒あたり 200 ～ 250 バイトのサイズの 100 の更新をクライアントに送信します (トピックごとに 2 秒で 1 つの更新)。問題は、これらを約 20 ～ 30 分間送信した後、フロー制御が開始され、フロー制御のために 1 ～ 2 時間後に更新が 5 ミリ秒から 100 ミリ秒遅れることです。Control Client を拡散して発行するためのフロー制御を回避する方法はありますか?
maxqueuesize は 10000 拡散 API ログに設定されています: pressure=0.04622500000000004 => 4 ミリ秒スリープ
フロー制御は、v5.1 で Java クライアントに、v5.5 で .NET クライアントに導入されました。フロー制御は、クライアント セッションを閉じてしまう内部キュー オーバーフローを防ぐために存在します。それは、根底にあるより深い問題を裏切る症状です。
これは、いくつかの理由で発生しています。
Diffusion サーバーがワークロードに追いついていません。しばらくするとこれが発生するので、サーバーの JVM がガベージ コレクションに時間をかけすぎているのではないかと思います。Java Missions Controlは、その質問にうまく答えます。
トピックの作成と更新の両方、およびMissing Topic Notificationsなどのイベントへの対応など、二重の役割を持つコントロール クライアントに影響を与えることがあまり見られません。フロー制御は、キューの飽和や満たされていない要求の数など、さまざまな要因の関数です。このような場合は、役割ごとに個別のセッションを検討してください。
2 番目の可能性に移る前に、1 番目のより単純な可能性を検討して検討してください。問題が解決しない場合は、support@pushtechnology.com までご連絡ください。
マーティン