Комментарии 20
А каково оно в сравнении, скажем, с Celery?
Celery больше функций, но она сложнее. Rq позволяет с минимальными затратами времени реализовать рабочее решение, Здесь очень хорошо описаны Про и Контра celery vs. rq, перевожу кратко:
У всех нас ограничено место в голове, поэтому если организация асинхронных очередей заданий для вас не основная работа, то RQ позволяет легко и просто построить качественное решение, за которое не будет стыдно. Celery конечно круче.
- Документация RQ полная и простая. Документация Celery сложнее для восприятия, хотя тоже подробная.
- Средства мониторинга Celery и RQ легко устанавливаются и оба хороши.
- Поддержка брокеров очередей: у RQ только Redis, Celery выигрывает (Redis, RabbitMQ). Redis, а значит RQ не гарантирует доставку 100% сообщений.
- Приоритетные очереди. Подходы разные, но оба работают.
- Операционные системы. RQ только unix-подобные (fork), Celery побеждает.
- Языки программирования. RQ только Python, Celery позволяет слать сообщения из одного языка другому (сорри).
- API. Celery гибче, RQ проще.
- Celery поддерживает подзадания, RQ — неизвестно (мне тоже неизвестно).
- Сообщество. Celery активнее, но оба проекта вполне активны.
У всех нас ограничено место в голове, поэтому если организация асинхронных очередей заданий для вас не основная работа, то RQ позволяет легко и просто построить качественное решение, за которое не будет стыдно. Celery конечно круче.
Статья любопытная, не знал про RQ. За статью — 5!) Но надо было остановиться после краткого сравнения.
Вот не надо опять про какие то там мистические ограничения в голове и особенно про «у всех нас».
Ограничения в голове только у всех вас, а за всех нас говорить нехорошо. Была бы карма, влепил бы комменту минус((
Вот не надо опять про какие то там мистические ограничения в голове и особенно про «у всех нас».
Ограничения в голове только у всех вас, а за всех нас говорить нехорошо. Была бы карма, влепил бы комменту минус((
> sudo pip install flask
Дальше не читал.
Дальше не читал.
helloworld.py
Для большей гибкости деплоя проекта, лучше изпользовать virtual env, а не ставить пакеты глобально.
НЛО прилетело и опубликовало эту надпись здесь
При чём здесь классификация картинок? Это отдельная тема. Дядя же ясно написал:
Естественно, его применение не ограничивается этими вашими нейронными сетями.
Смысл статьи в построении системы выполнения сравнительно длительных заданий. Вместо классификации картинок сервис может их ресайзить, например.
Это тянет на enterprise или все такие вариант прототипирования?
Формально такой функционал можно стандартными http.server и threading уложить строк в 30.
Формально такой функционал можно стандартными http.server и threading уложить строк в 30.
Скорее всего мне нужен так называемый data orchestration framework, но всё равно спрошу.
Есть ли возможность подключить несколько серверов разных конфигураций?
Есть возможность задавать разные типы тасков и разные типы воркеров?
Есть ли возможность запускать задачи которые описаны через directed acyclic graph? В этой связи больше интересует запуск с места в графе где задача зафейлилась.
Как это всё дебажить и мониторить(хотелось бы что то типа дашборда с метриками и т.д.)?
Есть ли возможность подключить несколько серверов разных конфигураций?
Есть возможность задавать разные типы тасков и разные типы воркеров?
Есть ли возможность запускать задачи которые описаны через directed acyclic graph? В этой связи больше интересует запуск с места в графе где задача зафейлилась.
Как это всё дебажить и мониторить(хотелось бы что то типа дашборда с метриками и т.д.)?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сделай сам веб-сервис с асинхронными очередями и параллельным исполнением