В последнее время понял, что мне не хватает местечка в интернете, где я мог быг бы писать небольшие статейки — что-то вроде pastebin-a на стероидах. Хотелось как раз иметь возможность модульно изменять контент. В итоге родился bluffy.net — при создании статьи есть возможность использовать HTML-редактор (redactor), редактор кода (ace) и вставлять галлереи из картинок (jquery galleria). Далеко от указанных в статье монстров, но, по-моему, получилось мило и достаточно удобно. Сайт пока совсем в бете и на дешевом дроплете digitalocean, но оценить функционал уже можно:)
решил воспользоваться bower в новом проекте, попробовал сначала django-bower, но в итоге остановился на чистом bower:
рядом с manage.py создал bower.json с необходимым содержимым, далее bower install ставит зависимости в директорию bower_components, которую нужно добавить в STATICFILES_DIRS.
Никаких дополнительных команд больше не нужно, статика находится, а collectstatic собирает всё, что нужно в STATIC_ROOT
при использовании основного клиента — так и нужно делать, в статье же речь о плагине, который является оберткой над основным клиентом и работает именно так, как описано. Немного не понял, при чем тут Knockout и Angular?
ZeroMQ дает некоторые интересные бонусы: brokerless, а также встроенный в библиотеку автоматический реконнект. Ну и интересно применять, конечно:) Но в целом, вы, конечно, правы. Думаю, несложно (и нужно) будет сделать Redis PUB/SUB механизм опциональным в будущих версиях.
Ответил чуть выше на аналогичный вопрос. Но попробую ответить еще раз, немного иначе. Существуют 2 вопроса в данном случае:
1) Redis или ZeroMQ для PUB/SUB
2) Зачем нужны разные бд
Насчет первого вопроса есть упоминание в самой статье. Я тоже в данный момент размышляю, не перейти ли полностью на Redis. Сейчас зависимость на Redis не жесткая.
Что касается второго — устанавливать и мониторить, конечно, придется. Но если вам не нужна возможность изменять динамически настройки проектов и пространств имен — можно описать структуру в конфиг-файле, в таком случае дополнительной зависимости не будет.
Пробовал за Haproxy в начале разработки, потом появился Nginx c поддержкой проксирования вебсокетов, перешел на него. В документации есть пример конфига.
Redis — это опция, без которой вполне можно обходиться. Не хотелось делать его использование обязательным. Если вам не нужна информация о клиентах в канале или история сообщений, то и Redis тут ни к чему. Настройки проектов и пространств имен нужно как-то хранить, так как они могут изменяться динамически. Согласен, вариантов получилось много, и чувство насчет мешанины — тоже есть, но пока так. Спасибо за замечание, этот момент действительно нужно будет обдумать.
Реконнект на стороне клиента предусмотрен. Реконнект PUB/SUB механизма на сервере осуществляет ZeroMQ.
Спасибо! Мне кажется, что одной из основных сложностей при использовании систем мониторинга является проблема конфигурации. Пока хостов несколько — всё хорошо, но чем больше становится, тем сложнее уследить за конфигом проверок. Есть ли какие-то идеи как можно улучшить этот момент?
Еще не могли бы вы рассказать про архитектуру бэкенда? Какие технологии используете, c какими сложностями столкнулись?
По этой ссылке совершенно другая картина. Добавились бенчмарки с количеством запущенных процессов по количеству ядер, и конечные результаты поменялись. По-моему, все не так уж неутешительно. А если взять Pypy в расчет — то и вовсе замечательно. Опять же, логично, что Erlang и Go показали лучшие результаты — оба языка спроектированы с уклоном на concurrency. В любом случае, какие бы ни были результаты, питон для Centrifuge был выбран не из соображений производительности.
Отношусь спокойно, так как выбрал для разработки язык, которым лучше владею. Конечно, Erlang в подобных серверах просто всеми красками расцветает, но сколько я за него не брался — никак не мог преодолеть рубеж между книгой и написанием чего-либо.
По вашей ссылке приведены плачевные результаты для Gevent, а я вижу, что у них в репозитории есть еще и Python c Tornado, не знаете, есть ли результаты для этой связки?
Пожалуй, вы правы. Поисследовал этот вопрос повнимательней — и да, скорее всего увеличения производительности нет, во многих тестах, которые я смог найти в интернете SSE не уступает вебсокетам по производительности. Думаю, это утверждение у меня на подсознательном уровне сформировалось и не хотелось так просто с ним расставаться. Спасибо.
Задержки на установку соединения сказываются на производительности, разве нет? Ну и также все общение при использовании SSE инкапсулируется в HTTP — а это промежуточные прокси, файрволлы, которые могут буфферизовать траффик, что приводит к увеличению времени ответа.
Server-Sent Events — это http протокол со всеми его оверхедами, WebSockets — это надстройка поверх TCP, изначально разработанная для обмена сообщениями между браузером и веб-сервером в режиме реального времени (wikipedia). Посмотрите вот на этот замечательный пост на SO — там многое объясняется.
спасибо за замечание, но не могли бы вы более подробно пояснить, что имеете в виду? В каком месте упростить и зачем обходить детектирование транспорта — поддержки вебсокетов в браузере ведь может и не быть?
bowerв новом проекте, попробовал сначалаdjango-bower, но в итоге остановился на чистом bower:рядом с
manage.pyсоздалbower.jsonс необходимым содержимым, далееbower installставит зависимости в директориюbower_components, которую нужно добавить вSTATICFILES_DIRS.Никаких дополнительных команд больше не нужно, статика находится, а
collectstaticсобирает всё, что нужно вSTATIC_ROOT1) Redis или ZeroMQ для PUB/SUB
2) Зачем нужны разные бд
Насчет первого вопроса есть упоминание в самой статье. Я тоже в данный момент размышляю, не перейти ли полностью на Redis. Сейчас зависимость на Redis не жесткая.
Что касается второго — устанавливать и мониторить, конечно, придется. Но если вам не нужна возможность изменять динамически настройки проектов и пространств имен — можно описать структуру в конфиг-файле, в таком случае дополнительной зависимости не будет.
Redis — это опция, без которой вполне можно обходиться. Не хотелось делать его использование обязательным. Если вам не нужна информация о клиентах в канале или история сообщений, то и Redis тут ни к чему. Настройки проектов и пространств имен нужно как-то хранить, так как они могут изменяться динамически. Согласен, вариантов получилось много, и чувство насчет мешанины — тоже есть, но пока так. Спасибо за замечание, этот момент действительно нужно будет обдумать.
Реконнект на стороне клиента предусмотрен. Реконнект PUB/SUB механизма на сервере осуществляет ZeroMQ.
Еще не могли бы вы рассказать про архитектуру бэкенда? Какие технологии используете, c какими сложностями столкнулись?
По вашей ссылке приведены плачевные результаты для Gevent, а я вижу, что у них в репозитории есть еще и Python c Tornado, не знаете, есть ли результаты для этой связки?