транслирует жизнеспособный вариант? Будет ли разница в производительности на конце сервера в зависимости от того, какой я выбираю? один лучше, чем другой для этого случая?длинные опросы vs streaming около 1 обновления/секунду
Я работаю над приложением GWT с Tomcat, работающим на сервере. Чтобы понять мои потребности, представьте себе обновление цен акций нескольких акций одновременно.
Вы хотите, чтобы процесс выполнялся с помощью клиента или сервера? Другими словами, хотите ли вы нажимать новые данные клиентам сразу, как только они будут доступны, или вы предпочтете, чтобы клиенты запрашивали новые данные, когда они сочтут нужным, хотя это может быть не один раз/секунду? В чем заключается вероятность того, что клиент сможет оставаться в ожидании ответа? Даже если вы ожидаете, что события будут происходить раз в секунду, сколько времени потребуется между запросом клиента и возвратом с сервера? Если это длиннее секунды, я бы ожидал, что вы настроитесь на то, чтобы направить события клиентам, хотя, наоборот, я ожидаю, что опрос будет в порядке. Если ответ длится дольше, чем интервал, то вы по существу потоки, так как к моменту, когда клиент получает последний, готово новое событие, поэтому клиент может по существу постоянно опросить и всегда получать события - в этом случае потоковое данные на самом деле будут более легкими, поскольку вы удаляете служебные данные соединения/согласования из процесса.
Я подозреваю, что загрузка сервера будет выше для клиентской (pull) подписки вместо потоковой конфигурации, так как клиенту придется повторно согласовывать соединение каждый раз, вместо того, чтобы оставлять открытое соединение, но каждое открытое соединение в потоковой модели потребует также ресурсов сервера. Это зависит от того, какой компромисс между тем, насколько агрессивным является ваш переговорный процесс, и насколько требуется память/обработка для каждого открытого соединения. Я не эксперт, так что могут быть и другие факторы.
ОБНОВЛЕНИЕ: This guy рассказывает о компромиссах между длинным опросом и потоковой передачей, и он, кажется, говорит, что с помощью протокола HTTP/1.1 процесс повторного согласования соединений является тривиальным, так что это не так много.
Конечно, если вы хотите использовать данные, потоковая передача, по-видимому, обеспечит лучшую производительность, если ваш сервер сможет обрабатывать ожидаемое количество непрерывных подключений. Но есть еще одна проблема, которую вы не адресуете: вы интернет или интранет? Сообщается, что потоковая передача имеет некоторые проблемы с прокси-серверами, как и следовало ожидать. Таким образом, для решения общего назначения вам, вероятно, будет лучше обслуживаться длительный опрос - для интрасети, где вы понимаете сетевую инфраструктуру, потоковая передача - это, скорее всего, более простое и лучшее решение для вашей производительности.
Потоковая передача будет быстрее, потому что данные только пересекают провод в одну сторону. При опросе латентность не менее двух раз.
Опрос более устойчив к сбоям в сети, поскольку он не полагается на открытое соединение.
Я бы пошел на опрос только для надежности.
Я хотел бы уточнить, что мой вопрос касается долгого опроса, а не традиционного опроса. Кроме того, NIO должен быть данным. – jcee14
Вы правы, NIO разбивает поток на ограничение соединения, уменьшая потребность в потоке. –
Для цен на живые цены я полностью поддерживал бы соединение и обеспечивал бы предупреждение/повторное подключение пользователя к отключению.
StreamHub GWT Comet Adapter был разработан именно для этого сценария потоковых котировок акций. Пример: GWT Streaming Stock Quotes. Он одновременно обновляет цены акций нескольких акций. Я думаю, что реализация под Comet, которая по существу потоковая передача по HTTP.
Редактировать: для каждого браузера используется различная техника.Цитирует сайт:
Есть несколько различной основных методы, используемой для реализации Comet включая Hidden плавающего фрейм, XMLHttpRequest/Script Long Polling, и встроенные плагин, такие как Flash. Введение в HTML 5 WebSockets в будущих браузерах предоставит альтернативный механизм для HTTP Streaming. StreamHub использует подход «наилучшего соответствия» , который использует наиболее эффективные и надежную технику для каждого браузера .
Это не имеет большого значения. Издержки на переключение соединения настолько тонкие с HTTP1.1, что вы не заметите каких-либо существенных различий в производительности так или иначе.
Выгоды от длительного опроса являются совместимость и надежность - никаких проблем с прокси, порты, обнаруживая отсоединяется и т.д.
Выгоды от «истинного» потокового бы потенциально уменьшить накладные расходы, но, как уже упоминалось, это польза намного, намного меньше, чем это было сделано.
Лично я считаю, что хорошо спроектированный кометный сервер является лучшим решением для большого количества обновлений и/или серверного нажатия.
Привет, rwmnau, ссылка, которую вы указали, освещает. Чтобы ответить на ваши вопросы, я хотел бы сделать данные пользователями, как только они будут доступны. – jcee14
Если вы хотите как можно скорее отправить данные пользователям, я думаю, что выбор должен быть потоковым, так как это будет поддерживать push-based соединение. С настройкой pull вы ожидаете, что клиенты спросят, но с нажатием они будут иметь данные, как только вы их дадите им. Дайте мне знать, что вы в конечном итоге выбираете и почему! – SqlRyan