CometD long polling - Does it scale nicely to high traffic? - scalability

Question

If I use CometD long polling:
Suppose there are 1000 messages in a second to be sent to subscribers, does CometD allow them to be auto-batched so that each client doesn't have to re-connect for each single message?
Do "lazy channels" (as described here: http://docs.cometd.org/3/reference/#_java_server_lazy_messages) auto-batch queued messages sent to clients upon timeout?
If on the other hand I don't use lazy channels, and suppose I "batch-publish" messages on channels 1, 2 and 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)
does a client subscribed to all 3 channels receive them in a batch too? Or does it send them all separately, forcing the client to re-connect after each message (slow)?

Answer 1

CometD offers application developers full control of batching features, allowing to have maximum flexibility, performance and scalability.
When using the HTTP long-polling transports, there are 2 places where batching may happen.
From client to server is solved using the CometD API and explicit batching (like your snippet above).
Batching at this level is typically in control of the application, although CometD does an internal batching to avoid exhausting the connections to the server.
From server to client there are more variations.
For broadcast non-lazy channels there is no automation, and what normally happens is that the first message to a client (that is not the publisher) will trigger the flush of the message queue; while this is being sent, other messages will queue up on the server side for that client and on the next /meta/connect the whole queue will be flushed. For 10 messages the scheme could be something like: 1-flush-9-flush (enqueue 1, flush the queue, enqueue the other 9 while waiting for the /meta/connect to come back, flush the other 9).
For broadcast lazy channels there is automation, so CometD will wait before sending those messages following the rules of lazy messages. A typical scheme could be: 10-flush.
For service channels, everything is back in control of the application.
The client can send batched messages to the application via a service channel (whose messages are not broadcast automatically by CometD). The application on server can receive the first message and know that other 9 will come, so it can wait to send them until the last has arrived. When the last arrives, it can just use the batching API to batch together the responses to clients, something like:
List<ServerSession> subscribers = ...;
for (ServerSession subscriber : subscribers) {
subscriber.batch(() -> {
subscriber.deliver(sender, "/response", response1);
subscriber.deliver(sender, "/response", response2);
subscriber.deliver(sender, "/response", response3);
});
}
Of course responses may be different from the messages received, both in content and number.
The scheme here can be almost anything the application wants, but it's common to have it as a 10-flush, which is the most efficient.
A note regarding the batching of messages to be sent back to the publisher. This is a special case and it's by default automated: while processing the incoming messages from that publisher, CometD starts an internal batch for that particular publisher, so that any message that is to be delivered back to the publisher is batched and will be flushed at the end of the processing of the incoming messages.
The bottom line is that CometD is already pretty well tuned to give the maximum of performance and scalability in common cases, but yet leaves the application room for customizing the behaviour to achieve maximum efficiency using application specific knowledge of message patterns.
I encourage you to look at the CometD documentation, tutorials and javadocs.