that this application will be used by a small number of administrative users, so it's not going to be used by thousands of users simultaneously.
Ну по моим тестам, топик тянет сотню соединений на воркер не напрягаясь. Больше не тестил. Вебсокет достаточно сложно протестировать тем же питоном. Была мысль написать на NodeJS клиента который будет открывать сокеты, но руки не дошли как-то.
А почему на сервере отъедается порт? Разве сервер не слушает один порт, а клиенты на него соединяются? Чую какой-то подвох и костыль в стиле запуск приложения в отдельном воркере и проксирование на него входящих соединений.
Тут возникает целая куча проблем. Например, если я закрою вкладку в которой у меня открыт коннекшн, что делать остальным, кому установить соединение, как они выберут мастера???
ИМХО: * в DNS A записи и генерация субдомена при соединении из случайной строки, и 255 соединений куда реалистичнее.
Не помню, разрабатывалось это где-то пол года назад. На WAMP я смотел, и что-то мне не понравилось, убей не помню что. Сейчас, очень похоже, они сильно выросли.
Понимаю вашу реакцию и спасибо за развернутый ответ. Статья предназначена скорее не вам, однако ваш опыт был бы очень полезен проекту в целом.
У вас судя по всему есть свой проверенный временем подход. В моей реализации (на моем проекте где используется crew), в целом, все workers — stateless и роль «ведущих машинок» выполняет RabbitMQ и пяток серверов с tornado, по которым размазывает 2 haproxy. База MongoDB поэтому вопрос шардирования и репликаций решен та том уровне. Но никто не мешает написать логику шардирования в воркере и бегать по шарду из SQLBased СУБД.
AMQP толст — если размер Payload'a будет меньше размера Header'а
Любая распределенная система (я говорю не об одной ноде с RabbitMQ а о кластере хотя-бы из двух трех нод) это overhead на пересылку пакетов по сети сериализацию/десериализацию. Хотите «тонкий» протокол общения ок, используйте 0MQ (кладите все в «shared memory» наконец), хотите работать на 10 виртуалках в облаке, планируйте жизнь с неким overhead.
Масштабировать вертикально с помощью AMQP в рамках одной ноды — ересь!
Именно поэтому слово «распределенный» и является ключевым. В статье нет ни слова о вертикальном масштабировании, crew это именно про горизонтальное масштабирование.
Хотите строить «распределённые» сервисы — проводите нагрузочное тестирование jMeter'ом и Яндекс.танком и профилируйте до потери пульса!
Согласен, сурового highload добиться можно только так. Сейчас речь идет скорее о надежности (непроизвольный отвал нескольких нод и тому подобные жизненные реалии). Сейчас версия модуля 0.7.0, у меня он покрывает все кейсы, работает и все суровые баги я уже почистил, сейчас начинаю всестороннее тестирование. Если вам интересен проект, давайте проведем нагрузочные или интеграционные тесты, помогите проекту.
Статья называется «Как просто написать распределенный веб-сервис на Python + AMQP» и тут нет и намека на суровый highload. Но у меня на практике в основном все упиралось не в amqp и не в данный модуль, а скорее в базу, которую ходят воркеры.
В случае highload слово «просто» вообще отпадает. Кто нибудь видел «простой» highload кластер наяву?
В примере есть TimeoutError и ExpirationError которые выбрасываются в зависимости от того что с задачей. Первая в случае если таск был взят, но воркер не обработал его за ttl. Вторая если таск так никто и не взял. А обрабатывайте сами — это значит, что можно попробовать повторить или сказать клиенту 500 404 etc. Вобщем в зависимости от требований. А идея wsgi-worker и предпологает решение всего что касается wsgi средствами этого wsgi слоя.
С распределением нагрузки по серверам не так уж и плохо справляется nginx
Да только вот если к вам придет 10к запросов, nginx сразу их пошлет на backend. И тут уж вашему приложению придется самому справляться с нагрузкой. В данном же случае, у вас все ляжет в очередь, и workerы потихоничку и без напряга все отработают.
Зачем же вообще wsgi это для того чтобы вы максимально не переписывали код, просто запустили уже работающее приложение.
Я про версии кода приложения. Без проблем называете несовместимый по запросу/ответу таск «app.mysupertask.v1» и фронтенд с уже обновленным кодом все будет слать на новые воркеры. Даже если вы остановите все воркеры, у вас приходящие сообщения будут копиться в очереди (учитывая timeout который вы уже обработаете сами), а после запуска воркеров, все побежит.
На самом деле ответ кроется в названии. «распределенный веб-сервис» это именно тот самый кейс. Когда у вас части системы живут отдельно на разных машинках.
Отличный вопрос, у celery действительно похожая идеология, но немного не тот подход. А так да, почти celery, но заточена на amqp-фичи, типа DLX и прочего.
RabbitMQ хорошо работает когда вам нужно выполнять таски на нескольких серверах. В пределах одного сервера Rabbit представляет из себя суровую пушку стреляющую по воробьям, для этого лучше подходит, например, 0MQ.
Конечно, речь идет о распределенной системе, которая работает на нескольких серверах. На одном сервере тоже можно, но для разработки ИМХО. А вот в боевых условиях, можно тиражировать воркеров как угодно, и единственное что им нужно это связь с RabbitMQ.
На клиент сайде так же можно сделать обвязку поверх транспортного уровня, чтобы не писать напрямую в вебсокет (socket.io или sockjs).
Немного не понял о чем вы.
В идее с wsgi есть проблема, по крайней мере если вы рассматриваете торнадо как фронтенд и воркеры как бэкенд обработки. Воркеры работают с чистыми данными, им не нужен request и заголовки, сессии и прочее, с этим должен работать торнадо. Уровень wsgi здесь кажется лишним, так как сразу напрямую можно использовать объекты бизнес-логики без каких-либо дополнительных прослоек.
Идея с wsgi в том, чтобы взять django/flask/etc. приложение и запустить его «воркером». Тогда на все ноды с приложением, будет равномерно распределена нагрузка + очереди.
Ну по моим тестам, топик тянет сотню соединений на воркер не напрягаясь. Больше не тестил. Вебсокет достаточно сложно протестировать тем же питоном. Была мысль написать на NodeJS клиента который будет открывать сокеты, но руки не дошли как-то.
ИМХО: * в DNS A записи и генерация субдомена при соединении из случайной строки, и 255 соединений куда реалистичнее.
У вас судя по всему есть свой проверенный временем подход. В моей реализации (на моем проекте где используется crew), в целом, все workers — stateless и роль «ведущих машинок» выполняет RabbitMQ и пяток серверов с tornado, по которым размазывает 2 haproxy. База MongoDB поэтому вопрос шардирования и репликаций решен та том уровне. Но никто не мешает написать логику шардирования в воркере и бегать по шарду из SQLBased СУБД.
Именно поэтому слово «распределенный» и является ключевым. В статье нет ни слова о вертикальном масштабировании, crew это именно про горизонтальное масштабирование.
Согласен, сурового highload добиться можно только так. Сейчас речь идет скорее о надежности (непроизвольный отвал нескольких нод и тому подобные жизненные реалии). Сейчас версия модуля 0.7.0, у меня он покрывает все кейсы, работает и все суровые баги я уже почистил, сейчас начинаю всестороннее тестирование. Если вам интересен проект, давайте проведем нагрузочные или интеграционные тесты, помогите проекту.
Статья называется «Как просто написать распределенный веб-сервис на Python + AMQP» и тут нет и намека на суровый highload. Но у меня на практике в основном все упиралось не в amqp и не в данный модуль, а скорее в базу, которую ходят воркеры.
В случае highload слово «просто» вообще отпадает. Кто нибудь видел «простой» highload кластер наяву?
Зачем же вообще wsgi это для того чтобы вы максимально не переписывали код, просто запустили уже работающее приложение.
Я про версии кода приложения. Без проблем называете несовместимый по запросу/ответу таск «app.mysupertask.v1» и фронтенд с уже обновленным кодом все будет слать на новые воркеры. Даже если вы остановите все воркеры, у вас приходящие сообщения будут копиться в очереди (учитывая timeout который вы уже обработаете сами), а после запуска воркеров, все побежит.
Должен работать уже, т.к. ACK на задачу посылается после ее обработки. И если убить воркер до посыла ACK задачу RabbitMQ переназначит другому.
Этот вопрос я бы на вашем месте расписал подробнее. Что понимается под версионностью кода.
Опять же на совести разработчика. Worker это просто функция, лично у меня есть декоратор который шлет в sentry ошибки.
Конечно, речь идет о распределенной системе, которая работает на нескольких серверах. На одном сервере тоже можно, но для разработки ИМХО. А вот в боевых условиях, можно тиражировать воркеров как угодно, и единственное что им нужно это связь с RabbitMQ.
Немного не понял о чем вы.
Идея с wsgi в том, чтобы взять django/flask/etc. приложение и запустить его «воркером». Тогда на все ноды с приложением, будет равномерно распределена нагрузка + очереди.