LINUX.ORG.RU

Как лучше организовать веб-приложение с долгой обработкой запроса и внешними сервисами?

 ,


2

3

Собственно, что оно будет делать:

  • запрашивать тексты с 1 сервиса
  • обрабатывать их 2 сервисом
  • возвращать результат обработки

    Притом - обработка может быть весьма долгой.

    Предпочёл бы python (ноды с го это, конечно, хорошо - но не то, освоением чего я бы хотел сейчас заняться). Соответственно - есть мысль сделать следующее :

  • реализовать всю вышеуказанную работу
  • таск под это дело в celery

    Тогда - я смогу запускать задачу в celery, возвращать идентификатор, проверять её статус и по готовности - возвращать инфу о результате.

    Собственно - есть ли явно лучшие методы?

    И да - в python3.5 вроде завезли кучу всего асинхронного. С учётом того, что у меня одно дерганье внешних сервисов - вроде бы может дать профит. Вопрос в том, не будет ли в случае применения celery явных подводных камней?

И да - в python3.5 вроде завезли кучу всего асинхронного. С учётом того, что у меня одно дерганье внешних сервисов - вроде бы может дать профит.

Думаю, для такой задачи тебе подойдёт tornado, он поддерживает asyncio и всякие long-polling, так что возможно сможешь обойтись и без сельдерея.

grazor ()
Последнее исправление: grazor (всего исправлений: 1)
Ответ на: комментарий от grazor

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

alozovskoy ★★★★★ ()
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

как организовать все эти запросы на сервере

Не приходилось решать подобную задачу, но, думаю, aiohttp client должен справиться. А вместо торнадо тогда можно взять aiohttp server.

grazor ()
Ответ на: комментарий от alozovskoy

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

Не только. Торнадо и aiohttp client/server работают внутри eventloop'а, позволяя веб-серверу осуществлять http-запросы, ожидание выполнения которых не будет блокировать работу сервера.

Нагуглил небольшой пример использования aiohttp. Нечно подобное будет происходить внутри хэндлеров сервера, не мешая ему обрабатывать другие запросы.

grazor ()
Ответ на: комментарий от grazor

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

anonymous ()

Если хочешь 3.5 и всяких модных вещей посмотри на Sanic, говорят очень быстрый.

ggrn ★★★★★ ()
Ответ на: комментарий от anonymous

дробить задачи в лупе я бы не стал

Согласен, зависит от того, что у ТСа за задача. Для небольших нагрузок и несложной обработки можно обойтись одним лупом, для чего-то посерьёзнее лучше будет взять task queue.

grazor ()
Ответ на: комментарий от grazor

Был ли у вас опыт в использовать в бою? Я только на лолкахосте поигрался и все.

ggrn ★★★★★ ()
Ответ на: комментарий от ggrn

Пока тоже на локалхосте гоняю, пилю небольшой сайтик на 100-200 пользователей.

grazor ()
Ответ на: комментарий от grazor

У меня печальный экспириенс с aiohttp из-за вот этого бага: https://github.com/KeepSafe/aiohttp/issues/1474 (скорее всего продолжение https://github.com/aio-libs/yarl/issues/21).

В общем, оно некорректно работает с form data. У убил несколько дней на эту проблему, она вылезала в самых неожиданных местах. Даже если если передать raw POST body оно всё равно валилось внутрях. Чтобы не переписывать всё с нуля пришлось вкорячивать в асинхронный код python-requests чему я был весьма недоволен. Я никого ни от чего не отговариваю, просто делюсь опытом.

true_admin ★★★★★ ()

Всем спасибо, попробуй копнуть в сторону tornado. Всё равно в моём случае вебморда - меньшая из проблем :-)

alex4321 ()

Бери месседж брокер, и обрабатывай данные в нем, асинхроность не работает в блокирующих операциях

rikimaru ()
Последнее исправление: rikimaru (всего исправлений: 1)
Ответ на: комментарий от rikimaru

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

asyncio.open_connection
. А у меня оно почти всё время и будет ждать ответа от одного изних :-)

Впрочем, голова у меня сейчас откровенно чугуниевая. Могу и упускать что-то.

alex4321 ()
Ответ на: комментарий от alex4321

Впринцыпе да, даже брокер не нужен, разверни просто сервис второй для долгих запросов и асинхронно жди ответа

rikimaru ()

Тут простой принцип:

1) если запрос долгий, потому что он грузит CPU или выполняет блокирующие операции, то надо либо использовать синхронную обработку запросов (prefork, и если сервер смотрит в инет то перед ним обязательно поставить какой-нибудь nginx), либо мутить очереди заданий и отдельные воркеры. Первый вариант реализуется проще, но масштабироваться может хуже

2) твой случай - ответ ожидает завершения сетевого запроса (неблокирующей операции) - делаешь асинхронный сервер, который во время ожидания обрабатывает других клиентов

annulen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.