длительный опрос по сравнению с потоковой передачей продолжительностью около 1 обновления в секунду

Question

является ли потоковое вещание жизнеспособным вариантом?будет ли разница в производительности на стороне сервера в зависимости от того, что я выберу?является ли одно из них лучше другого для данного случая?

Я работаю над приложением GWT с Tomcat, запущенным на стороне сервера.Чтобы понять мои потребности, представьте, что цены на акции нескольких компаний обновляются одновременно.

Answer 1

Вы хотите, чтобы процесс был управляемым клиентом или сервером?Другими словами, хотите ли вы отправлять клиентам новые данные, как только они станут доступны, или вы предпочли бы, чтобы клиенты запрашивали новые данные всякий раз, когда сочтут нужным, даже если это может происходить не один раз в секунду?Какова вероятность того, что клиент сможет задержаться и дождаться ответа?Даже если вы ожидаете, что события будут происходить один раз в секунду, сколько времени проходит между запросом от клиента и возвратом с сервера?Если это больше секунды, я бы ожидал, что вы склонитесь к тому, чтобы передавать события клиентам, хотя, наоборот, я бы ожидал, что опрос пройдет нормально.Если ответ занимает больше времени, чем интервал, то вы, по сути, в любом случае выполняете потоковую передачу, поскольку к тому времени, когда клиент получает последнее событие, новое событие готово, поэтому клиент может, по сути, постоянно опрашивать и всегда получать события - в этом случае потоковая передача данных на самом деле была бы более легкой, поскольку вы устраняете накладные расходы на подключение / согласование из процесса.

Я бы заподозрил, что нагрузка на сервер будет выше для клиентской подписки (pull), а не для потоковой конфигурации, поскольку клиенту пришлось бы каждый раз заново согласовывать соединение, вместо того чтобы оставлять соединение открытым, но каждое открытое соединение в потоковой модели также потребовало бы ресурсов сервера.Это зависит от того, каков компромисс между тем, насколько агрессивен ваш переговорный процесс исколько памяти / обработки требуется для каждого открытого соединения.Однако я не эксперт, так что могут быть и другие факторы.

Обновить: Этот парень рассказывает о компромиссах между длительным опросом и потоковой передачей, и он, кажется, говорит, что с HTTP / 1.1 процесс повторного согласования соединения тривиален, так что это не такая большая проблема.

Answer 2

На самом деле это не имеет значения.Накладные расходы на повторное согласование соединения с HTTP1.1 настолько невелики, что вы так или иначе не заметите каких-либо существенных различий в производительности.

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

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

Лично я считаю, что хорошо спроектированный сервер comet является лучшим решением для большого количества обновлений и / или принудительной отправки на сервер.

Answer 3

Конечно, если вы хотите передавать данные, потоковая передача, по-видимому, обеспечит лучшую производительность, если ваш сервер сможет обрабатывать ожидаемое количество непрерывных подключений.Но есть еще одна проблема, которую вы не решаете:Вы выходите в Интернет или интранет?Сообщалось, что при потоковой передаче через прокси-серверы возникли некоторые проблемы, как и следовало ожидать.Таким образом, для решения общего назначения вам, вероятно, лучше подойдет длительный опрос - для интрасети, где вы разбираетесь в сетевой инфраструктуре, потоковая передача, скорее всего, является более простым и производительным решением для вас.

Answer 4

В StreamHub GWT Comet Адаптер был разработан именно для этого сценария потоковой передачи биржевых котировок.Пример здесь: Котировки акций GWT Streaming.Он обновляет цены на акции нескольких компаний одновременно.Я думаю, что нижеприведенной реализацией является Comet, которая по сути является потоковой передачей по HTTP.

Редактировать:Он использует разную технику для каждого браузера.Цитировать веб-сайт:

Существует несколько различных базовых методов, используемых для реализации Comet включая скрытый iFrame, Длительный опрос XMLHttpRequest / Script, и встроенные плагины, такие как Flash.Внедрение HTML 5 WebSockets в будущих браузерах предоставит альтернативный механизм для HTTP Потоковой передачи.StreamHub использует "наилучший подход" подход, использующий наиболее производительный и надежный метод для каждого браузера.

Answer 5

Потоковая передача будет быстрее, потому что данные передаются по проводу только в одну сторону.При опросе задержка увеличивается как минимум в два раза.

Опрос более устойчив к перебоям в работе сети, поскольку он не зависит от того, что соединение остается открытым.

Я бы пошел на опрос просто ради надежности.

Answer 6

Для текущих цен на акции я бы обязательно оставил соединение открытым и обеспечил оповещение пользователя / переподключение при отключении.