Добрый день, уважаемые Хабраюзеры. Недавно мне поставили задачу сделать визуализацию постоянного потока данных в виде вебстраницы. Данные идут сплошным потоком такого вида
То есть в начале строки идентификатор элемента(назовем его датчиком), а после двоеточия через пробел начинаю идти состояния «датчика» каждую секунду. Вот мне и нужно показать на вебстранице все датчики(их могут быть десятки и сотни) и актуальное на данный момент значение состояния. Сами состояния сохранять не нужно, после показа их можно спокойно удалять(сбор статистики идет отдельно), а значит вместо бд, можно использовать мемкеш. если я не ошибаюсь его скорости должно хватить даже если интервалы будут не секундные, а например 100мс. Хотя я в сомнении нужна ли вообще какая то база — данные идут выводятся в stdout, может сразу их брать и визуализировать? Понятное дело что обычный html4/xhtml и ajax тут не справится, а вот средствами html5, судя по тому что я видел, вполне можно такое организовать. но к сожалению у меня пока не было времени основательно разобраться с новыми возможностями и все самому попробовать, потому и прошу совета. Как бы вы реализовали такую задачу?(обязательное требование вывод на вебстраницу, а не в отдельный гуй) Какие технологии бы использовали — webgl, websockets, итд?
Пожалуй уточню, я знаю как решить эту задачу стандартными средствами(AJAX, long polling, передача клиенту только изменений индикаторов, без передачи самих данных). И благодаря комментам ниже я уже сообразил как обойти большинство «затыков/граблей» о которых я думал изначально. Спасибо за это. Но я не зря в тегах и вопросе упомянул HTML5 — мне очень интересен практический опыт тех кто уже делал что нибудь с использованием новых возможностей. Конкретнее интересует их мнение по поводу того стоит ли применять эти технологии в данном случае, насколько сложно в них разобраться с нуля, будет ли это решение менее ресурсоемким или может более быстрым, отзывчивым? Ну а те кому не лень читать мои простыни текстов могут в комментах ниже посмеяться над тем как я вначале тупил, к каким выводам пришел и поправить меня если где-то не прав или есть более оптимальный метод.
что мешает представить эти данные в виде бесконечного «длинного файла»? и яваскриптом на лету парсить и отображать? другое дело что это совсем не оптимально, из обсуждения я пришел к выводу что лучше всего будет парсить поступающие данные сразу на стороне сервера, при первом показе страницы переслать всю «картину» клиенту и отобразить, а потом посылать только данные о внесении изменений. тоесть на сервере проверка показала что датчик из зеленой зоны перешел в желтую — сразу отправляем эту инфу клиенту, инфу о остальных датчиках не отправляем если ничего не менялось. В таком случае можно использовать long-polling как мне кажется, «цвет» датчиков будет сменятся не так часто. Кстати работать это будет в гигабитной локалке, такчто думаю и в 100мс даже сплошным потоком эти данные бы укладывались:) Но смысла напрягать клиентский браузер не вижу.
Мне кажется, слишком сложные варианты вам предлагают. Я бы сделал буферизацию поступающих данных через memcache, а затем выдачу данных из кеша в ответ на ежесекундные http-запросы. Для этого достаточно любого скриптового языка на стороне сервера (python, php и т.п.).
вот это и было первое мое решение, которое пришло в голову когда еще вопрос не запостил. но после обсуждения тут, понял насколько оно сырое. нам не нужно передавать сами данные клиенту, достаточно передавать только состояния датчиков которые соответствуют этим данным. в итоге буферизация не нужна вообще, все данные на лету парсяться на сервере, в клиент передается инфа только о том что нужно изменить. ну а передавать эту инфу уже можно по разному, хоть вебсокеты/флеш(самое оптимальное в плане нагрузки на клиента имхо), хоть ежесекундные http-запросы(больше всего нагрузят и клиент и сервер), хоть long-polling/comet…
очень просто. на клиентской стороне непрерывно запрашивать новые данные XmlHttpRequestом, а на серверной стороне отдавать их только тогда, когда поступили новые данные; до тех пор просто держать соединение открытым. такой подход называется поллинг (кажется), а почитать про всё это можно тут
этот способ я знаю, но я не уверен что он тут к месту частота смены данных будет очень большая — скорее всего 50-100мс. вы уверены что броузер не загнется обрабатывая 10-20 хтмлреквестов в секунду и рендеря новую картинку? Я конечно уже подумал о том что намного удобнее делать собирать данные в небольшие блоки, получать среднее значение а страницу обновлять раз в 5 секунд. естественно учитывая все аномальные результаты в таких блоках, но заказчик хочет «прям вот риалтайм отображение всех данных» — даже если человек на глаз их различить не успеет. Ну и так как это не для широкого круга пользователей то можно не ограничивать себя в выборе броузера, потому я сразу и подумал о хтмл5 — использовать сокеты для обмена данными(скорее всего понадобится двухсторонний обмен — на сервер нужно будет передавать команды запуска/остановки/изменения параметров), а на канвасе например рисовать «карту» датчиков — по идее это значительно быстрее чем изменение DOM. Вот только практического опыта нет — хотелось бы выяснить стоит ли счас в попыхах подучить хтмл5 ради более качественной реализации, или делать по старинке потому что выигрыша не будет.
Может тогда flash с открытым сокетом спрятать и он будет отдавать Javascript'у данные и тот уже рендерить?
Вобщем мне кажется Вам нужно копать в сторону IRC веб морд, там примерно тоже самое.
вы похоже не уловили почему мне кажется эта идея неверной, все чаты и иркморды в том числе обновляют страницу не так уж часто, потому без проблем работают, а в моем случае нужно успевать угробить старые данные и показать новые за доли секунды, но даже если «схитрить» и обновлять раз в секунду то представьте что будет если на странице сотня датчиков(страховаться от такого думаю табами с небольшими группами датчиков)
ну, это зависит от реализации, некоторый часто, хотя согласен, не доли секунд.
Ваш вопрос в том как данные передавать с такой скоростью или как их отображать (выдержит ли браузер)?
Имхо html5 тяжелее flash.
та я уже понял что желание клиента это хорошо, но все же нужно в разумных пределах реализовывать. буду анализировать данные на серверной стороне и посылать клиенту только изменения состояния датчиков, так и перерисовывать страницу не нужно будет тысячи раз и данных передаваться лишних не будет. проблемы нагрузки в таком случае практически не будет.
Если обновлять данные со скоростью 50-100мс, то у пользователя в глазах будет лишь рябь. Логично, что обновление лучше производить не чаще 1 раза в секунду.
Браузер должен нормально рендерить эти запросы, ведь вы будете обновлять не всю страницу, а только блоки с цифрами (кстати, не забудьте указать им position: absolute, иначе обновляться будет вся страница). WebSockets пока ненадежны. Их то включают в стандарт, то исключают, т.е. нет никакой уверенности, что с обновлением браузера их поодержка не пропадёт.
Поэтому остается поллинг. Или вообще сделайте на java/flash'e, где есть нормальная поддержка нормальных сокетов.
ряби не будет просто потому что данные будут соответствовать всего нескольким цветам и 95% времени данные по конкретному датчику будут на одном уровне — тоесть спрайт не будет менятся, сам только что сообразил что это значительно снизит нагрузку на клиентской стороне — перерисовывать придется только изредка.Для наблюдателя это будет выглядеть как стенд светодиодов: горит зеленым — все в норме, горит желтым — нужно проверить, горит красным — срочно чинить, черный — деталь накрылась… както так, только у зеленого и желтого будут дополнительные градации.
ну а за то что вебсокеты пропадут из стандарта я не переживаю — это очень маловероятно. java/as мне однозначно не подходят — не люблю эти языки, потому не слежу и не вникаю — а значит и толкового ничего не сделаю. потому наверно будет утилитка на С(которая генерит данные)+ питон(в крайнем случае пхп) на сервере+js/jquery на клиенте.
Теперь общая картинка уже вырисовывается, но мне все еще интересно мнение тех кто разрабатывал «отзывчивые» интерфейсы(например у хтмл5 игрушек) с использованием канваса: на сколько сложно разобраться сначала, насколько быстро изменяется «полотно», насколько сильно это напрягает комп.
аа, если только цвета менять и не выводить цифр, тогда да, все нормально. Вот только как у вас будет вызываться серверная часть, анализирующая данные и решающая посылать обновления на клиенты или нет? ПХП с кроном тут явно не вариант.
Если вы контролируете пользовательское окружение (грубо говоря, можете сказать каким браузером пользователю пользоваться), то WebSockets вполне нормальное решение для этого, про опрос сервера вообще забываете, это он шлёт браузеру информацию когда она изменяется (в идеале). Беда в том, что сейчас WebSokets из популярных браузеров поддерживает только Chrome. FF4, похоже, выйдет без поддержки, хотя в ранних бетах была :(
фрейм хрома можно даже в ие поставить… но мне больше нравится функция хрома — Создать ярлыки приложений, выглядит практически как отдельное приложение, работает быстро, не зависит от других запущенных копий хрома. Да вебсокеты для меня самое удобное решение, посмотрим как выйдет с реализацией.
Простой
