0

CometD ロング ポーリングを使用する場合:

サブスクライバーに送信されるメッセージが 1 秒間に 1000 件あるとします。CometD では、各クライアントがメッセージごとに再接続する必要がないように、メッセージを自動バッチ処理できますか?

「遅延チャネル」(ここで説明されているように: http://docs.cometd.org/3/reference/#_java_server_lazy_messages ) は、タイムアウト時にクライアントに送信されたキューに入れられたメッセージを自動バッチ処理しますか?

一方、遅延チャネルを使用せず、チャネル 1、2、および 3 でメッセージを「バッチ公開」するとします。

cometd.batch(function()
{
    cometd.publish('/channel1', { product: 'foo' });
    cometd.publish('/channel2', { notificationType: 'all' });
    cometd.publish('/channel3', { update: false });
});

( http://docs.cometd.org/3/reference/#_javascript_batch )

3 つのチャネルすべてにサブスクライブしているクライアントもバッチでそれらを受信しますか? それとも、それらをすべて個別に送信し、各メッセージの後にクライアントに再接続を強制しますか (遅い)?

4

1 に答える 1

1

CometD は、アプリケーション開発者にバッチ機能の完全な制御を提供し、最大限の柔軟性、パフォーマンス、およびスケーラビリティを実現します。

HTTPlong-pollingトランスポートを使用する場合、バッチ処理が発生する可能性のある場所が 2 つあります。

クライアントからサーバーへは、CometD API と明示的なバッチ処理 (上記のスニペットのように) を使用して解決されます。このレベルでのバッチ処理は通常、アプリケーションによって制御されますが、CometD はサーバーへの接続を使い果たすことを避けるために内部バッチ処理を行います。

サーバーからクライアントまで、さらにバリエーションがあります。

遅延のないブロードキャスト チャネルの場合、自動化は行われません。通常は、クライアント (パブリッシャーではない) への最初のメッセージによって、メッセージ キューのフラッシュがトリガーされます。これが送信されている間、他のメッセージがそのクライアントのサーバー側でキューに入れられ、次に/meta/connectキュー全体がフラッシュされます。10 個のメッセージの場合、スキームは次のようになります: 1-flush-9-flush (1 をキューに入れ、キューをフラッシュし、が戻ってくるのを待っている間に他の 9 をキューに入れ、他の 9 をフラッシュし/meta/connectます)。

ブロードキャスト遅延チャネルには自動化があるため、CometD は遅延メッセージのルールに従ってメッセージを送信する前に待機します。典型的なスキームは次のようになります: 10-flush。

サービス チャネルの場合、すべてがアプリケーションの制御下に戻ります。クライアントは、サービス チャネル経由でアプリケーションにバッチ処理されたメッセージを送信できます (メッセージは CometD によって自動的にブロードキャストされません)。サーバー上のアプリケーションは、最初のメッセージを受信し、他の 9 つのメッセージが来ることを認識できるため、最後のメッセージが到着するまでメッセージの送信を待機できます。最後の応答が到着すると、バッチ API を使用して、クライアントへの応答をまとめてバッチ処理できます。たとえば、次のようになります。

List<ServerSession> subscribers = ...;
for (ServerSession subscriber : subscribers) {
    subscriber.batch(() -> {
        subscriber.deliver(sender, "/response", response1);
        subscriber.deliver(sender, "/response", response2);
        subscriber.deliver(sender, "/response", response3);
    });
}

もちろん、応答は、内容と数の両方で、受信したメッセージとは異なる場合があります。ここでのスキームは、アプリケーションが必要とするものであれば何でもかまいませんが、最も効率的な10-flushにするのが一般的です。

パブリッシャーに返送されるメッセージのバッチ処理に関するメモ。これは特殊なケースであり、デフォルトで自動化されています。そのパブリッシャーからの着信メッセージを処理している間、CometD はその特定のパブリッシャーの内部バッチを開始します。これにより、パブリッシャーに返送されるメッセージはバッチ処理され、着信メッセージの処理の終了。

要するに、CometD は、一般的なケースで最大のパフォーマンスとスケーラビリティを提供するようにすでに十分に調整されていますが、アプリケーション固有のメッセージ パターンの知識を使用して最大の効率を達成するために、アプリケーションの動作をカスタマイズする余地が残されています。

CometD のドキュメント、チュートリアル、および javadocsを参照することをお勧めします。

于 2014-10-05T15:37:13.577 に答える