Длинный опрос CometD - хорошо ли он масштабируется для большого трафика?

Question

Если я использую CometD длинный опрос:

Предположим, что в секунду отправляется 1000 сообщений подписчикам. Разрешает ли CometD их автоматическую упаковку, чтобы каждому клиенту не приходилось повторно подключаться к каждому отдельному сообщению?

Имеют ли "ленивые каналы" (как описано здесь: http://docs.cometd.org/3/reference/) автоматическую пакетную отправку сообщений в очередь, отправленных клиентам по истечении времени ожидания?

Если, с другой стороны, я не использую ленивые каналы, и предположим, что я "пакетно публикую" сообщения на каналах 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/)

клиент, подписанный на все 3 канала, тоже получает их в пакете? Или он отправляет их все по отдельности, заставляя клиента переподключаться после каждого сообщения (медленно)?

Answer 1

CometD предлагает разработчикам приложений полный контроль над функциями пакетирования, позволяя им иметь максимальную гибкость, производительность и масштабируемость.

При использовании HTTP long-polling транспорты, есть 2 места, где может произойти дозирование.

От клиента к серверу решается с помощью API CometD и явного пакетирования (как ваш фрагмент выше). Пакетирование на этом уровне обычно контролирует приложение, хотя CometD выполняет внутреннее пакетирование, чтобы избежать исчерпания соединений с сервером.

От сервера к клиенту есть больше вариантов.

Для широковещательных не ленивых каналов автоматизация отсутствует, и обычно происходит следующее: первое сообщение клиенту (не издателю) вызовет сброс очереди сообщений; в то время как это отправляется, другие сообщения будут стоять в очереди на стороне сервера для этого клиента и на следующем /meta/connect вся очередь будет сброшена. Для 10 сообщений схема может выглядеть примерно так: 1-flush-9-flush (поставить в очередь 1, очистить очередь, поставить в очередь остальные 9, ожидая /meta/connect чтобы вернуться, смойте остальные 9).

Для трансляции ленивых каналов предусмотрена автоматизация, поэтому CometD будет ожидать отправки сообщений в соответствии с правилами ленивых сообщений. Типичная схема может быть: 10-флеш.

Что касается сервисных каналов, все вернулось под контроль приложения. Клиент может отправлять пакетные сообщения приложению через служебный канал (сообщения которого не передаются автоматически 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-флеш, что является наиболее эффективным.

Примечание о пакетировании сообщений для отправки обратно издателю. Это особый случай, и по умолчанию он автоматизирован: при обработке входящих сообщений от этого издателя CometD запускает внутренний пакет для этого конкретного издателя, так что любое сообщение, которое должно быть доставлено обратно издателю, упаковывается и сбрасывается в окончание обработки входящих сообщений.

Суть в том, что CometD уже довольно хорошо настроен, чтобы обеспечить максимальную производительность и масштабируемость в обычных случаях, но при этом оставляет возможность приложениям настраивать поведение для достижения максимальной эффективности, используя специфические знания приложений о шаблонах сообщений.

Я рекомендую вам взглянуть на документацию по CometD , учебные пособия и javadocs.