Многие реализации комет, такие как Caplin, обеспечивают масштабируемые серверные решения.
Ниже приведена одна из статистических данных Caplin:
Один экземпляр освободителя Caplin может поддерживать до 100 000 клиентов, каждый из которых получает 1 сообщение в секунду со средней задержкой менее 7 мс.
Как это сравнить с веб-сайтами HTML5 на любом веб-сервере? Может ли кто-нибудь указать мне на статистику HTML-страниц HTML 5?
Раскрытие информации - я работаю для Caplin.
На этой странице немного дезинформации, поэтому я хотел бы попытаться сделать ее более ясной.
Я думаю, мы могли бы разделить методы, о которых мы говорим, в три лагеря.
Я вижу их всех как комету, поскольку комета - всего лишь парадигма, но, поскольку WebSocket приходил, некоторые люди хотят относиться к ней так, как будто она отличается или заменяет комету, - но это просто еще один метод - и если вы не счастливы, последние браузеры, то вы не можете просто полагаться на WebSocket.
Что касается производительности, большинство тестов сосредоточено на сообщениях сервера с клиентами - количество пользователей, количество сообщений в секунду и латентность этих сообщений. Для этого сценария нет принципиальной разницы между потоковым потоком HTTP и WebSocket - оба записывают сообщения в открытый сокет с небольшим или отсутствующим заголовком или служебными данными.
Длительный опрос может дать хорошую задержку, если частота сообщений низкая. Однако, если у вас есть два сообщения (от сервера к клиенту) в быстрой последовательности, то второй не будет появляться на клиенте до тех пор, пока новый запрос не будет получен после получения первого сообщения.
Я думаю, кто-то коснулся HTTP KeepAlive. Это, очевидно, может улучшить длительный опрос - у вас все еще есть накладные расходы на округление и заголовки, но не всегда создание сокета.
Где WebSocket должен улучшать потоки HTTP в сценариях, где есть больше сообщений от клиента к серверу. Сопоставление этих сценариев с реальным миром создает несколько более произвольные настройки, по сравнению с простым для понимания "отправлять много сообщений большому количеству клиентов", которые каждый может понять. Например, в торговом приложении создание сценария, в котором вы включаете пользователей, выполняющих сделки (например, сообщения клиента на сервер), легко, но результаты немного менее значимы, чем сценарии базового сервера для клиента. Трейдеры не пытаются делать 100 сделок/сек, поэтому вы получаете результаты, такие как "10000 пользователей, получающих 100 сообщений в секунду, одновременно отправляя сообщение клиента каждые 5 минут". Более интересной частью сообщения клиента для сервера является задержка, так как количество требуемых сообщений обычно незначителен по сравнению с сообщениями сервера и клиента.
Еще один момент, который сделал выше, около 64 тыс. клиентов. Вам не нужно делать что-нибудь умное, чтобы поддерживать более 64 тыс. сокетов на сервере - кроме настройки дескрипторов файлов файлов и т.д. Если вы пытались выполнить соединение 64k с один клиентский компьютер, который совершенно другой, так как им нужен номер порта для каждого из них - на конце сервера это нормально, но это конец прослушивания, и вы можете отлично разбираться в сокетах размером 64 КБ.
В теории, WebSockets может масштабироваться намного лучше, чем HTTP, но есть некоторые предостережения и некоторые способы устранения этих оговорок.
Сложность обработки заголовка рукопожатия HTTP vs WebSockets примерно такая же. Рукопожатие HTTP (и начальное WebSocket) может быть легко превышено 1K данных (из-за файлов cookie и т.д.). Важное различие заключается в том, что сообщение об ошибке HTTP снова появляется каждое. Как только соединение WebSocket установлено, служебные данные для каждого сообщения составляют всего 2-14 байтов.
Отличные ссылки на Jetty, размещенные в ответе @David Titarenco (1, 2) показывают, что WebSockets может легко достичь более порядка лучшей латентности по сравнению с Comet.
Подробнее о масштабировании WebSockets vs HTTP см. .
Предостережения
Соединения WebSocket долговечны, в отличие от HTTP-соединений, которые недолговечны. Это значительно снижает накладные расходы (без создания сокетов и управления для каждого запроса/ответа), но это означает, что для масштабирования сервера выше 64 тыс. Отдельных одновременных клиентских хостов вам необходимо использовать трюки, такие как несколько IP-адресов на одном сервере.
Из-за проблем с безопасностью веб-посредников сообщения браузера на сервер WebSocket содержат все данные полезной нагрузки XOR в маске. Это добавляет некоторое использование ЦП на сервер для декодирования сообщений. Тем не менее, XOR является одной из наиболее эффективных операций в большинстве архитектур процессоров, и часто предоставляется аппаратная поддержка. Сообщения сервера для браузера не замаскированы, и поскольку многие использования WebSockets не требуют больших объемов данных, отправленных из браузера на сервер, это не большая проблема.
Трудно понять, как это сравнивается ни с чем, потому что мы не знаем, насколько большой (средний) размер полезной нагрузки. Под капотом (как и в том, как реализован сервер) потоки HTTP и веб-узлы практически идентичны - помимо первоначального рукопожатия, которое сложнее, когда сделано с HTTP явно.
Если вы написали свой собственный сервер websocket в C (ala 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/
Однако, если вы посмотрите на тесты C event lib, такие как libev и libevent, цифры выглядят значительно сексуальнее:
http://libev.schmorp.de/bench.html
Игнорирование любой формы опроса, которое, как объясняется в другом месте, может привести к задержке, когда скорость обновления высока, три наиболее распространенных метода для потоковой передачи JavaScript:
WebSocket на сегодняшний день является самым чистым решением, но по-прежнему существуют проблемы с точки зрения браузера и сетевой инфраструктуры, которые не поддерживают его. Чем скорее это можно опираться на лучшее.
XHR/XDR и Forever IFrame оба хороши для передачи данных клиентам с сервера, но требуют, чтобы различные хаки выполнялись последовательно во всех браузерах. По моему опыту, эти подходы Comet всегда немного медленнее, чем WebSockets, не в последнюю очередь потому, что для его работы требуется гораздо больше кода JavaScript на стороне клиента - с точки зрения сервера, однако отправка данных по проводу происходит с одинаковой скоростью.
Вот еще графические графики WebSocket, на этот раз для нашего продукта My-Channels Nirvana.
Пропустить диаграммы многоадресной и двоичной данных вплоть до последнего графика на странице (высокая скорость обновления JavaScript)
В заключение. Результаты показывают, что Nirvana WebSocket обеспечивает 50 событий в секунду для пользователей 250000 пользователей с задержкой в 800 микросекунд. У 5000 пользователей (всего 250 тыс. Событий/сек потоки) латентность составляет 2 миллисекунды.