Python-сообщество

Вопрос не совсем по питону.
Планируется разработка сайта в основном для отображения данных на веб страничках и чуток для взаимодействия с пользователями.
Параметры выдачи:
до 3000 элементов на странице, темп обновления изображения 50 миллисекунд. Ну если получится конечно. Некоторые источники данных естественно трактовать как вектора. Перечень данных для отрисовки не меняется.
Сеть локалка. Основные элементы наверное svg хотя можно и ctx. Количество контролов пользователя до 100 на страницу.
Латентность при реакции на воздействия пользователя (клики) не более 300 миллисекунд.

Время загрузки страниц не нормируется.

Полное число отображаемых сигналов не более 1000000. Одновременно работающих клиентов не более 10.

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

Какую посоветуете технологию для привязки данных к изображению на странице (angular, ReactJS, Backbone.js, knockout, d3, xslt, просто ручками написать, по возможности утянув формирование картинок на сервер).

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

Количество различных типов отображающих элементов не более 1000. Но это все равно требует решения вопроса об организации их разработки и использования.

Какой формат передачи данных для этого подходит? (msgpack. trift, protocol buffer?)
Ну и конечно потянет это flask? Хотя понятно, сервер тут не особо критичен.

Как по вашему возможно такое соорудить?

Отредактировано doza_and (Дек. 4, 2015 22:00:55)

doza_and
до 3000 элементов на странице

doza_and
Полное число отображаемых сигналов не более 1000000

doza_and
различных типов отображающих элементов не более 1000

У меня есть не очень удачный опыт с angularjs - по нему, на таком количесве элементов он будет тормозить.
По поводу остальных - есть же бенчмарки, они вас не устравивают? )

doza_and
утянув формирование картинок на сервер

А вот это - плохая идея, imho - проще отрисовать все состояния и отдавать как css-спрайт, иначе вы забьете канал и не сможете добится своих показателей.

s0rg
есть же бенчмарки, они вас не устравивают? )

Бенчмарки одно, а живой опыт совсем другое. Задача очень специфическая. Судя по тестам надо заниматься велосипедостроением или использовать относительно низкоуровневые библиотеки ReactJS, d3.js

s0rg
А вот это - плохая идея

Я имел ввиду что “элемент отображения” сначала строится по одной группе данных из СУБД, а потом это изображение обновляется по другой, значительно меньшей группе. Первичное построение, происходящее во время загрузки страницы можно выполнить на сервере или на стороне клиента. Время выполнения этой операции не очень критично. Тут скорее важно удобство построения и модификации большой группы объектов. И тут дилема. С одной стороны, удобно описывать объекты на языке близком к логике построения изображения в броузере. Те javascript. Но с объектным подходом и организацией множества модулей там туго. REQUIREJS не очень спасает ситуацию. В питоне гораздо проще создать структуру из наследуемых друг от друга графических объектов, которые однако будут тогда создаваться на сервере.

Простейшие тесты показали, что особой разницы во времени не будет. Не оптимизированная страница размером 500 Кб грузится 0.6-0.8 секунды в обоих случаях.

Возможен промежуточный вариант. http://www.brython.info/. Удобен и с точки зрения организации javascript объектов, доступ к native объектам броузера выглядит намного более привлекательно чем в родном javascript. Использование javascript вставок тоже элементарно. Но пока технология сыровата. Время загрузки аналогичных страниц возрастает до 1.5 -2 секунд. Можно это исправить Переписав критические куски на javascript. Но это делает такой подход не очень удобным. Особенные опасения вызывают медленные циклы. Скорее всего обновление данных с темпом 20 раз в секунду на brython сделать нельзя. Ну и конечно отсутствие адекватных механизмов отладки тоже не плюс brython. Но в целом для простых сайтов вполне себе достойный вариант.

Может кто пробовал https://github.com/PythonJS/PythonJS http://coffeescript.org/ ? Мне они показались малоперспективными. Фактически обновления не идут. Дополнительная фаза компиляции, терпима, но не плюс. Какое у вас мнение?

doza_and
Разные источники не рекомендуют использовать ангуляр если планируется больше 2000-3000 вотчеров.
Однако, я запускал 15000 вотчеров без ощутимых тормозов. Вероятно всё зависит от клиентской машины.

FishHook
Вероятно всё зависит от клиентской машины.

Безусловно, конкретно мои проблемы были с мобильными устройствами )

doza_and
Посмотрите еще на typescript

http://chrisharrington.github.io/demos/performance/
тут 1к элементов и о 50ms приходится мечтать (при том что данные уже погружены и пример простой)
а все отображаемые элементы в localstorage клиентов загнать нельзя?
для сервера crossbar.io + msgpack посмотри, вебсокеты + rpc

по поводу brython - не уверен что он готов для использования в проде, лучше coffeescript/ts взять

Отредактировано slav0nic (Дек. 11, 2015 14:04:14)

slav0nic
лучше coffeescript/ts взять

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

Спасибо, обязательно посмотрю. Потом напишу что получилось. Пока конец года все закрывают этапы :)

Я вот думаю, а не быстрее будет забить на DOM и все отрисовывать на один большой канвас?