hockey_new/README_BUILD189_RU.txt

BUILD189 — снижение нагрузки при двух одновременных матчах
Версия: 2026.10.02.9. Обновление поверх BUILD188 (2026.10.02.8).

ЧТО ИСПРАВЛЕНО

1. Одинаковые ежесекундные live-события больше не запускают дополнительные
   запросы списка Agent и справочника удалений. Для каждого списка допускается
   один запрос одновременно; смена матча, языка, сессии и ручные действия
   сохраняют обновление. Устаревший ответ не отменяет более свежую настройку.
2. Заголовок соблюдает интервал чтения состояния матча. Диагностика получает
   начальный статус, затем опрашивает сервер при открытой панели.
3. Автообновление Mapping выполняется независимо для каждого Agent. Медленный
   SQL или соединение одного Agent не задерживает следующий цикл другого.
   На устройство приходится максимум одна фоновая работа. Отключённые Agent
   и пустой план не вызывают частые пустые циклы.
4. Список Agent использует уже загруженные записи устройств. Профили игроков
   и судей матча читаются пакетно вместо отдельных SELECT для каждого человека.
5. При изменении только счёта, времени или событий сохраняются актуальный матч
   и полный RU/EN JSON; неизменённые составы и статистика не перезаписываются.
   Изменения статистики, состава и тренера продолжают сохраняться сразу.
   Проверка целостности восстанавливает отсутствующие строки статистики.
6. Чтение стартовых данных интерфейса выполняется через ограниченный пул
   DB-работников, освобождая основной цикл HTTP/WebSocket. Отмена запроса
   дожидается окончания или отката DB-работы и сохраняет лимит параллельности.

ИЗМЕРЕНИЯ И ПРОВЕРКИ

Локальный тест: два разных матча по 44 игрока, справочник 1000 игроков,
изолированная SQLite, внешняя сеть и дополнительные броски подменены.
Изменился только счёт двух матчей:
  до:    242 SQL-вызова, медиана 138 мс;
  после:  26 SQL-вызовов, медиана 65 мс.
При искусственной задержке 2 мс на SQL: 769 → 111 мс.
Это результат указанного сценария, а не замер вашего PostgreSQL/сервера.
Если меняется сама статистика, её необходимые записи выполняются.

Браузерный тест: 10 одинаковых live-событий, ответы по 2 секунды:
  список Agent: 27 → 4 запроса, одновременно 6 → 1;
  справочник удалений: 11 → 1, одновременно 3 → 1.
Состояние заголовка: 10 → 5 запросов за 10 секунд.
Закрытая диагностика: 13 → 1 запрос за минуту.

Проверены независимое обновление двух Agent при задержке SQL/соединения,
остановка фоновых задач, смена аккаунта/матча/языка/сессии, ручные звенья,
времена на льду, статистика вратаря, RU/EN, откат и повторная попытка,
полная/частичная потеря строк статистики и порядок справочника удалений.
Проверки native таймеров, удаления при выданном верхнем счёте и снятия
Delay Penalty прошли; их runtime совпадает с доставленным BUILD188.
В старом тесте Mapping осталось ожидание GUID Input: тот же тест падает
на исходной BUILD188. Рабочая привязка по названию Input сохранена.

ЗАМЕНА ФАЙЛОВ

В архиве 8 изменённых файлов приложения и эта инструкция:
  app.py
  hockey_data/async_work.py
  hockey_data/agent_bridge.py
  hockey_data/service.py
  hockey_data/static/agent-devices.js
  hockey_data/static/admin-directories.js
  hockey_data/static/match-status-header.js
  hockey_data/static/agent-diagnostics.js

Сохраните копии этих файлов, распакуйте архив в корень проекта с заменой,
перезапустите службу приложения и обновите браузеры операторов через Ctrl+F5.
Проверьте версию 2026.10.02.9. Используются существующие конфигурации и база.
Обновление Agent и миграция схемы для этого исправления не требуются.

РЕКОМЕНДАЦИИ ДЛЯ СЕРВЕРА

Ориентир для двух матчей после этого обновления:
  приложение, PostgreSQL на отдельном сервере: 4 vCPU, 8 ГБ RAM, SSD;
  приложение и PostgreSQL на одной машине: 8 vCPU, 16 ГБ RAM, SSD.
Это стартовая оценка с запасом, а не измеренный минимум или гарантия:
расход зависит от SQL, объёма базы, числа браузеров и фоновых импортов.
Для приложения предусмотрите от 20 ГБ диска; объём PostgreSQL, журналов
и резервных копий рассчитывается отдельно по фактическому росту данных.
Обработка графики vMix выполняется на компьютере с vMix; GPU веб-серверу
для данного приложения не нужен.

1. Для текущей архитектуры запускайте один процесс приложения:
   .venv/bin/python -m uvicorn app:app --host 0.0.0.0 --port 8000 --workers 1
   Запуск с --reload оставьте для разработки. У проекта WebSocket-соединения
   Agent, очереди и планировщики хранятся в памяти процесса. Несколько workers
   без общего брокера могут разнести HTTP-запрос и Agent по разным процессам
   и запустить несколько фоновых импортов. Масштабирование на несколько
   процессов требует отдельной доработки владения соединениями и задачами.
2. Начните с текущих лимитов: HOCKEY_DB_WORKERS=8, HOCKEY_DB_POOL_SIZE=10.
   Увеличение числа потоков само по себе не ускоряет тяжёлый SQL. Сначала
   проверьте загрузку PostgreSQL, задержку соединения и длительность запросов.
   Общий верхний предел соединений пула равен pool_size + max_overflow.
3. В Mapping интервал 1 секунда оставляйте данным, которым действительно
   нужна такая частота, например надписям удалений. Для менее срочной
   статистики можно выбрать 3–5 секунд, для статичных данных 10–30 секунд
   либо обновление кнопкой. При нажатии кнопки её SQL обновляется отдельно.
   Интервалы в этом обновлении автоматически не меняются.
4. Держите PostgreSQL близко к приложению по сети. Для медленных операторских
   SQL проверяйте план и индексы по используемым game/player/tournament ID.
   Массовый импорт КХЛ выполняйте в предусмотренном ночном запуске;
   дополнительный полный ручной прогон лучше делать вне эфира.
5. После замены сравните CPU по процессам/ядрам, RAM и swap, disk I/O,
   задержку базы в панели «Диагностика», ошибки SQL и отклик двух матчей.
   Для точной настройки нужны число vCPU, RAM, команда запуска без секретов,
   расположение PostgreSQL и показатели во время задержки.

Документация:
https://uvicorn.dev/settings/
https://fastapi.tiangolo.com/advanced/websockets/
https://docs.sqlalchemy.org/en/20/core/pooling.html