Масштабируемость сервера - HTML 5 веб-сокетов против Comet

Question

Многие реализации Comet, такие как Caplin, предоставляют масштабируемые серверные решения.

Ниже приводится одна из статистических данных Caplin сайта:

Один экземпляр освободителя Caplin может поддерживать до 100 000 клиентов, каждый из которых получает 1 сообщение в секунду со средней задержкой менее 7 мс.

Как это сравнить с веб-сокетами HTML5 на любом веб-сервере? Может ли кто-нибудь указать мне статистику веб-сокетов HTML 5?

Answer 1

Раскрытие информации - я работаю на Caplin.

На этой странице есть некоторая дезинформация, поэтому я хотел бы попытаться сделать ее более понятной ..

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

1. Опрос кометы HTTP - включая длительный опрос
2. Потоковая передача кометы HTTP - сообщения от сервера к клиенту используют один постоянный сокет без заголовка HTTPнакладные расходы после начальной установки
3. Comet WebSocket - один двунаправленный сокет

Я вижу их всех как Comet, поскольку Comet - это всего лишь парадигма, но, поскольку WebSocket появился вместе, некоторые люди хотят относиться к немукак будто он другой или заменяет Comet - но это просто еще один метод - и если вы не удовлетворены только поддержкой последних браузеров, вы не можете просто полагаться на WebSocket.

Что касается производительности, то большинство тестов производительностисконцентрируйтесь на сообщениях от сервера к клиенту - количество пользователей, количество сообщений в секунду и задержка этих сообщений.Для этого сценария нет принципиальной разницы между потоковой передачей HTTP и WebSocket - обе записывают сообщения в открытый сокет с небольшим заголовком или без заголовка или без него.

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

Я думаю, что кто-то коснулся HTTPKeepAlive.Это, очевидно, может улучшить длинный опрос - у вас все еще есть накладные расходы на передачу данных и заголовки, но не всегда на создание сокета.

Где WebSocket должен улучшить HTTP Streaming в сценариях, где больше сообщений от клиента к серверу.Связывание этих сценариев с реальным миром создает немного больше произвольных настроек, по сравнению с простым для понимания «отправкой большого количества сообщений множеству клиентов», который может понять каждый.Например, в торговом приложении создание сценария, в котором вы включаете пользователей, совершающих сделки (т. Е. Сообщения от клиента к серверу), является простым, но результаты немного менее значимы, чем сценарии базового сервера к клиенту.Трейдеры не пытаются совершить 100 сделок в секунду, поэтому вы получите результаты, например: «10000 пользователей получают 100 сообщений в секунду, а также отправляют клиентское сообщение каждые 5 минут».Более интересной частью сообщения от клиента к серверу является задержка, поскольку количество требуемых сообщений обычно незначительно по сравнению с сообщениями от сервера к клиенту.

Еще один момент, о котором кто-то упоминал выше, о клиентах 64 КБ, вы не делаете этого.Нужно сделать что-нибудь умное для поддержки более чем 64k сокетов на сервере - кроме настройки дескрипторов числовых файлов и т. д. Если вы пытались установить соединение 64k с одного клиентского компьютера, это полностью отличается, так как им нужен номер порта для каждогоодин - на стороне сервера это нормально, хотя это и конец прослушивания, и вы можете пойти выше 64k сокетов.

Answer 2

Теоретически WebSockets может масштабироваться намного лучше, чем HTTP, но есть некоторые предостережения и некоторые способы их устранения.

Сложность обработки заголовка рукопожатия в HTTP и WebSockets примерно одинакова.HTTP (и начальный WebSocket) рукопожатие может легко превышать 1 КБ данных (из-за файлов cookie и т. Д.).Важным отличием является то, что HTTP-рукопожатие происходит снова каждое сообщение.Как только соединение WebSocket установлено, накладные расходы на сообщение составляют всего 2-14 байт.

Превосходные ссылки на эталонный тест Jetty, опубликованные в ответе @David Titarenco ( 1 , 2 ) покажите, что WebSockets может легко достичь более латентной задержки порядка по сравнению с Comet.

См. этот ответ для получения дополнительной информации о масштабировании WebSockets противHTTP.

Предостережения :

• Соединения WebSocket являются долгоживущими в отличие от HTTP-соединений, которые недолговечны.Это значительно снижает накладные расходы (создание сокетов и управление каждым запросом / ответом не требуется), но это означает, что для масштабирования сервера выше 64 тыс. Отдельных одновременных клиентских хостов вам потребуется использовать приемы, например, несколько IP-адресов на одном сервере.

• Из-за проблем безопасности с веб-посредниками сообщения WebSocket от браузера к серверу маскируют все данные полезной нагрузки XOR.Это добавляет некоторое использование процессора серверу для декодирования сообщений.Тем не менее, XOR является одной из наиболее эффективных операций в большинстве архитектур ЦП, и часто имеется аппаратная помощь.Сообщения от сервера к браузеру не маскируются, и поскольку во многих случаях использование WebSockets не требует больших объемов данных, передаваемых из браузера на сервер, это не представляет большой проблемы.

Answer 3

Трудно понять, как это можно сравнить с чем-либо, потому что мы не знаем, насколько велик (средний) размер полезной нагрузки. Под капотом (как в том, как реализован сервер) потоковая передача HTTP и веб-сокеты практически идентичны - за исключением первоначального рукопожатия, которое, очевидно, более сложное, когда выполняется с HTTP.

Если бы вы написали свой собственный сервер веб-сокетов на C (аля Caplin), вы, вероятно, могли бы достичь этих цифр без особых затруднений. Большинство реализаций websocket выполняются с помощью существующих серверных пакетов (например, Jetty), поэтому сравнение на самом деле не будет справедливым.

Некоторые тесты :
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks/

Однако, если вы посмотрите на тесты lib для событий C, такие как libev и libevent, цифры выглядят значительно сексуальнее:
http://libev.schmorp.de/bench.html

Answer 4

Игнорирование любой формы опроса, которая, как объяснено в другом месте, может привести к задержке при высокой частоте обновления, три наиболее распространенных метода для потоковой передачи JavaScript:

1. WebSocket
2. Потоковая передача Comet XHR / XDR
3. Comet Forever IFrame

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

XHR / XDR и Forever IFrame отлично подходят для передачи данных клиентам с сервера, но для обеспечения согласованной работы различных браузеров требуются различные хаки.По моему опыту, эти подходы Comet всегда немного медленнее, чем WebSockets, не в последнюю очередь потому, что для его работы требуется намного больше кода JavaScript на стороне клиента, однако с точки зрения сервера отправка данных по сети происходит с той же скоростью.

Вот еще несколько графиков тестирования WebSocket , на этот раз для нашего продукта my-Channels Nirvana .

Пропуск графов многоадресной и двоичной информации до последнего графика на странице (высокая скорость обновления JavaScript)

В итоге - результаты показывают, что Nirvana WebSocket обеспечивает 50 событий в секунду до 250000kпользователи с задержкой 800 мкс.При 5000 пользователей (всего 250 тыс. Событий в секунду) задержка составляет 2 миллисекунды.