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

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

Предположим, что подписчикам отправляется 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 канала, тоже получает их пакетом? Или он отправляет их все по отдельности, заставляя клиента повторно подключаться после каждого сообщения (медленно)?


scalability broadcast batching server-push cometd
person Navigateur    schedule 05.10.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person sbordet    schedule 05.10.2014