29 lines
2.0 KiB
Markdown
29 lines
2.0 KiB
Markdown
# Вопрос к Опусу — фоновая классификация при 50+ файлах
|
||
|
||
## Что сделано
|
||
|
||
`POST /api/classify-batch` получает `{batch_id}`, запускает `classify_worker.py`
|
||
через `subprocess.Popen` и сразу возвращает `202 {total: N}`.
|
||
Фронтенд поллит `/api/batch-progress` каждые 2с пока `done >= total`.
|
||
|
||
`classify_worker.py` — отдельный питон-процесс, импортирует `services/classify.py`,
|
||
у которого внутри `ThreadPoolExecutor(max_workers=4)` для параллельных
|
||
LLM-вызовов (один файл = один LLM-запрос к api.aillm.ru).
|
||
|
||
## Проблема
|
||
|
||
С 4 файлами полный цикл работает. С 69 файлами:
|
||
- HTTP-сервер жив, `/health` отвечает
|
||
- `classify_worker` работает
|
||
- Симулятор с внешней машины не дожидается конца — на 5+ минутах рвётся сеть/nginx
|
||
|
||
## Вопросы
|
||
|
||
1. Архитектурно `subprocess.Popen` норм для прода? Или что-то более надёжное (очередь, systemd-таймер, воркер-пул)?
|
||
|
||
2. Что делать с nginx при долгих запросах? `batch-progress` — короткий поллинг, он не должен рваться. Но сам classify через фронтенд не идёт — только через воркер. Где узкое место?
|
||
|
||
3. При двух быстрых классификациях подряд — второй `Popen` создаст второй процесс. Старый ещё не умер. Надо проверять и убивать предыдущий? Или пусть оба работают (разные batch_id)?
|
||
|
||
4. Как правильно мониторить/логировать фоновый процесс? Сейчас stdout/stderr в `/dev/null`.
|