Карта: переиспользовать HTTP-соединения и убрать последовательное ожидание
Статус: предложение, не реализовано. Инвазивность: Низкая. Основа: webrtc-komaroff@772de4a, 16.09.2026.
Открытие карты сейчас создаёт новый ClientSession в init_map_handler, затем последовательно запрашивает каталог аэропортов и позицию. Эти данные нужны одновременно, но второй запрос ждёт окончания первого. После NATS reconnect браузер снова вызывает bootstrap. На маленьком каталоге это может быть незаметно; механизм всё равно добавляет работу на каждый повтор.
Core по-прежнему управляет начальной загрузкой карты. API по-прежнему возвращает данные, а NATS доставляет команды уже подписанному клиенту. Меняется жизнь соединения и порядок независимых запросов.
Предлагаемая правка
Создавать HTTP session при startup Core и закрывать через cleanup context. Ограничить connection pool и задать connect/read/total timeouts. Два независимых GET выполнять параллельно. Если позиция и каталог должны отражать одну версию данных, вместо параллелизма добавить один GET /api/map/bootstrap с согласованным snapshot; это уже изменение API.
Каталог можно отдавать с revision/ETag и кэшировать по версии. Позицию пользователя нельзя кэшировать как общий глобальный объект: текущий mock этого не показывает, а реальная интеграция потребует user/session scope.
Что изменится в числах
| Показатель | Подтверждённая исходная точка | Проверяемый результат |
|---|---|---|
| Создание ClientSession | 1 на bootstrap | 1 на lifecycle экземпляра Core |
| Последовательная цепочка API calls | 2 GET | 2 параллельных GET; либо 1 aggregate GET |
| Ожидание API без overhead | примерно T_airports + T_position | примерно max(T_airports, T_position) для параллельного варианта |
| Повторная передача каталога | полный payload в текущем пути | 304/кэш только при неизменной revision |
| p95 bootstrap, соединения/с | baseline отсутствует | измерить одинаковыми 1/10/50 одновременными открытиями |
Формула описывает устранение последовательного ожидания, а не обещает такое же ускорение всего экрана. Если основная задержка в тайлах MapLibre, это изменение почти не повлияет на ready-map.
Как принять и откатить
Проверить нормальный ответ, timeout каждого backend, повтор после reconnect и shutdown без unclosed-session warnings. Для aggregate endpoint сравнить поля и порядок UI-команд со старой версией. Сначала достаточно pool + parallel GET; endpoint и кэш можно принять отдельными MR.
Откат возвращает прежний handler без изменения хранилища. При маленькой частоте открытия карты приоритет ниже исправления повторных workflow.
Основания
init_map_handler, requestInitMap. Текущая документация aiohttp: persistent session рекомендует session с жизнью приложения и управляемым cleanup. Context7: /aio-libs/aiohttp, запрос о pooling и cleanup, 16.09.2026. Этот принцип применим к используемой 3.10.5; API новой версии нельзя переносить без проверки совместимости.
Все предложения · Фактическая архитектура