Сделать отдельный процесс и очередь на распознавание

[IlyaOvodov]

Сейчас запуск распознавания происходит синхронно с запросом пользователя.
Надо отделить одно от другого: чтобы задача на распознавание ставилась в очередь, а код, вызванный пользователем, или сразу возвращал управление пользователю, или ждал небольшое время, потом возвращал, даже если результата нет, и потом ожидал завершения распознавания.

[ongrid]

Здравствуйте. У нас есть опыт реализации асинхронной обработки фоновых задач. Готовы помочь с проектированием и реализацией. Предварительно набросал несколько идей.

Принцип следующий:

1. Методы, обработка которых занимает длительное время, потребляет много ресурсов, блокирует IO или GIL, выносится в отдельные от сервера (web-сервера, а точнее *SGI сервера a-la flask или aiohttp) процессы "воркеры".
2. Процессы могут быть размещены в т.ч. на другой инфраструктуре чем сам вебсервис (другие VM на одном хосте или даже других аппаратных хостах). Последнее похоже на ваш случай, т.к., как я понял, используется оффлоад на CUDA GPU.

На чем мы делали такое:

1. Request/Reply via REST. Вебсервис (flask) отправляет задачу в воркеры (aiohttp) по REST, воркер присваивает ей номер и синхронно возвращает id. Flask записывает id в локальную модель. Микросервис по готовности задачи возвращает результат в виде встречного запроса во flask по REST (webhook). Преимущества: простота, простой инструментарий. Похожие подходы разработки бэкенда и микросервисов.
2. Celery. Процесс, который обрабатывает фоновые задачи. Применяется, как правило, в комбинациии с Django. В качестве транспорта используется RabbitMQ. Был бы у вас Django, имело бы смысл начать с него. В других стэках преимуществ не вижу, можно применять п. 3.
3. Pika, Rabbitmq, Asyncio - микросервис-воркер реализуется на pure python, транспорт -AMQP (RabbitMQ). Инициатор (условный flask) отправляет задачу в очередь. Микросервисы берут сообщения из этой очереди work queues pattern. Обрабатывают и складывают результат в другую очередь, которую вычитывает инициатор. Преимущества: предельно высокая масштабируемость во всех измерениях (заложена легкая масштабируемость, миграция на другую очередь, например облачный сервис AWS, GCP тоже делается несложным рефакторингом). Недостатки: специфические процессы разработки и тестирования. Удобно применять в очень больших проектах, где за каждый из микроосервисов отвечает отдельная команда. В вашем случае - это overkill.

Я бы предварительно мог рекомендовать начать с варианта 1.

PS:
Frontend (UI) - частный случай вопроса достижениия асинхронности. Развязка делается путем осуществления асинхронных вызовов к вэб бэкенду (принцип называется SPA. Ну и частный случай, вы упоминали - PWA). Протокол общения фронтенда и бэкенда можно использовать тот же самый, что и описан в п.1 выше - REST. В т.ч. можно в некотором масштабе использовать его же и для уведомлений, инициированных сервером (через REST long polling).