долго опрашивая по сравнению с потоковой передачей относительно приблизительно 1 обновления/секунда
В добавление к ответу majkinetor, вот способ удаления конечного разделителя (поскольку я пока не могу просто комментировать его ответ):
ls -1 | awk 'ORS=","' | head -c -1
Просто удалите столько конечных байтов, сколько ваш разделитель считает для .
Мне нравится этот подход, потому что я могу использовать многосимвольные разделители + другие преимущества awk:
ls -1 | awk 'ORS=", "' | head -c -2
РЕДАКТИРОВАТЬ
Как заметил Питер, отрицательно Подсчет байтов не поддерживается в родной версии главы MacOS. Это, однако, может быть легко исправлено.
Сначала установите coreutils. «Основные утилиты GNU - это базовые утилиты для работы с файлами, оболочками и текстом в операционной системе GNU».
brew install coreutils
Команды, также предоставляемые MacOS, устанавливаются с префиксом «g». Например, gls.
Как только вы это сделаете, вы можете использовать ghead с отрицательным числом байтов или лучше, сделать псевдоним:
alias head="ghead"
6 ответов
Вы хотите, чтобы процесс управлялся клиентом или сервером? Другими словами, хотите ли вы отправлять новые данные клиентам, как только они станут доступны, или вы бы предпочли, чтобы клиенты запрашивали новые данные всякий раз, когда они сочтут нужным, даже если это может происходить не один раз в секунду? Какова вероятность того, что клиент сможет просто ждать ответа? Даже если вы ожидаете, что события будут происходить один раз в секунду, сколько времени проходит между запросом от клиента и возвратом с сервера? Если это больше секунды, я ожидаю, что вы склонитесь к тому, чтобы передать события клиентам, хотя, наоборот, я ожидал бы, что с опросом все в порядке. Если ответ занимает больше времени, чем интервал, то вы все равно транслируете потоковую передачу, поскольку там ' sa новое событие, готовое к тому времени, когда клиент получит последнее событие, поэтому клиент может постоянно опрашивать и всегда получать события - в этом случае потоковая передача данных будет более легкой, поскольку вы удаляете накладные расходы на соединение / согласование из
Я подозреваю, что нагрузка на сервер будет выше для клиентской (опрашивающей) подписки вместо потоковой конфигурации, поскольку клиенту придется каждый раз заново согласовывать соединение, вместо того, чтобы оставлять соединение open, но каждое открытое соединение в потоковой модели также потребует ресурсов сервера. Это зависит от компромисса между тем, насколько агрессивен ваш процесс переговоров, и тем, сколько памяти / обработки требуется для каждого открытого соединения. Я не эксперт, поэтому могут быть и другие факторы.
ОБНОВЛЕНИЕ:
Конечно, если вы хотите передавать данные, потоковая передача, по-видимому, обеспечивает лучшую производительность, если ваш сервер может обрабатывать ожидаемое количество непрерывных подключений. Но есть еще одна проблема, которую вы не решаете: вы Интернет или интранет? Сообщается, что потоковая передача имеет некоторые проблемы с прокси-серверами, как и следовало ожидать. Так что для решения общего назначения вам, вероятно, лучше подойдет длинный опрос - для интрасети, где вы понимаете сетевую инфраструктуру, потоковая передача, скорее всего, будет более простым и производительным решением для вас.
Потоковая передача будет быстрее, потому что данные передаются только в одном направлении. При опросе задержка как минимум в два раза.
Опрос более устойчив к сбоям в сети, поскольку он не полагается на то, что соединение остается открытым.
Я бы пошел на опрос только для надежности.
Адаптер StreamHub GWT Comet был разработан именно для этого сценария потоковой передачи котировок акций. Пример здесь: Котировки акций GWT Streaming . Он одновременно обновляет цены на несколько акций. Я думаю, что реализация ниже - это Comet, которая, по сути, передает поток через HTTP.
Изменить: она использует разные методы для каждого браузера. Процитируем веб-сайт:
Есть несколько различных основных методы, используемые для реализации Comet включая скрытый iFrame, XMLHttpRequest / Script Long Polling, и встроенные плагины, такие как Flash. Введение в HTML 5 WebSockets в будущем браузеры предоставят альтернативный механизм для HTTP Потоковое. StreamHub использует "наиболее подходящий" подход с использованием наиболее эффективных и надежная техника для каждого браузер.
Для текущих цен на акции я бы полностью оставил соединение открытым и обеспечил предупреждение пользователя / повторное соединение при отключении.
Это не имеет значения. Накладные расходы на повторное согласование соединения с HTTP1.1 настолько малы, что вы не заметите каких-либо существенных различий в производительности так или иначе.
Преимущества длительного опроса заключаются в совместимости и надежности - отсутствие проблем с прокси-серверами, портами, обнаружением разъединений и т. Д.
Преимущества «истинной» потоковой передачи потенциально могут снизить накладные расходы, но, как уже упоминалось, это преимущество намного меньше, чем кажется.
Лично я считаю, что хорошо спроектированный сервер кометы - лучшее решение для большого количества обновлений и / или push-уведомлений.