From 64728e4cccf115e49b542402e6c13a069ecec614 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= Date: Fri, 14 Aug 2026 20:11:03 +0400 Subject: [PATCH] =?UTF-8?q?HISTORY:=20Q&A=20=D0=A1=D0=BE=D0=BD=D0=BD=D0=B5?= =?UTF-8?q?=D1=82=D0=B0=20=D0=BF=D0=BE=20=D1=82=D0=B5=D1=81=D1=82=D0=B0?= =?UTF-8?q?=D0=BC=20+=20=D0=BF=D0=BB=D0=B0=D0=BD=20=D0=B4=D0=B8=D0=B0?= =?UTF-8?q?=D0=B3=D0=BD=D0=BE=D1=81=D1=82=D0=B8=D0=BA=D0=B8=20=D0=BF=D0=BB?= =?UTF-8?q?=D0=B0=D1=82=D1=84=D0=BE=D1=80=D0=BC=D1=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- HISTORY/2026-08-14-session-log.md | 34 +++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/HISTORY/2026-08-14-session-log.md b/HISTORY/2026-08-14-session-log.md index fc14d86..cabc3f6 100644 --- a/HISTORY/2026-08-14-session-log.md +++ b/HISTORY/2026-08-14-session-log.md @@ -608,3 +608,37 @@ DNS ВМ. Проверки ВМ: resolv.conf = один `8.8.8.8`; dig 20/20 о **Финальный 30-мин прогон**: запущен 18:30:52 +03 (ВМ) — в процессе. +## Q&A Соннета — какие ещё тесты провести (14.08.2026) + +**Вопрос (кратко)**: достаточен ли набор проверок; какие сценарии не покрыты; норма ли +ReadTimeout 0.04%; серверные таймауты; нужен ли CLI v2 в нагрузке; что ещё до релиза. + +**Ответ Соннета (ключевое)**: +- Не покрыто, но критично: рестарт пода с in-flight сообщениями (asyncWrite до смерти пода + → двойная доставка); unbounded goroutines при деградации Redis (OOM на 512Mi); + long-poll goroutine leak; FIFO-порядок под конкурентными receive; DLQ e2e; dedup-окно e2e. +- Восстановление очередей из Redis после рестарта — обязательный тест. +- ReadTimeout 0.042% — граница, снижать до <0.01%: проверить кластеризацию ошибок во времени + (lock contention vs gateway), keep-alive/RST на шлюзе, TCP retransmits пода. +- Серверные таймауты добавить: ReadHeaderTimeout 10s, WriteTimeout 35s (20с long-poll + буфер), + IdleTimeout 90s, MaxHeaderBytes 8192. ReadTimeout НЕ ставить (рвёт long-poll). +- AWS CLI v2 (query-mode JSON) в нагрузке — обязательно, другой путь сериализации. +- Память (RSS 2+ часа), billing-счётчики, JWT-истечение mid-request, лимит 50 очередей + (граница включительно), /metrics корректность после прогона. +- Приоритеты: P0 серверные таймауты + рестарт с in-flight; P1 Redis chaos + long-poll leak; + P2 CLI v2 нагрузка + FIFO dedup/DLQ e2e; P3 RSS. + +## План диагностики САМОЙ платформы (HTTP контейнер), независимо от SQS (14.08.2026) + +Пользователь: проверить, как HTTP-контейнер платформы сбоит сам по себе (аналогия: +managed flask/nodejs/lucee не пропускают большие файлы с локали). Отделяем транспорт от логики SQS. + +A. Через /health (минимум логики): burst 500 параллельных; большие заголовки 8–16KB; + медленный запрос (1 байт/с); keep-alive 50 запросов на одном соединении; HTTP/1.0, HEAD, POST. +B. Через SQS API, смотрим транспорт: SendMessage 256KB (с ВМ И с локальной машины); + chunked-тело; Receive 10×256KB (~2.5MB ответ); long-poll 20с (локаль vs ВМ). +C. Известные аномалии: GET /ui через ingress висит ~150с (внутри пода мгновенно); + ReadTimeout-кластеры; max latency 52с. +D. TCP: retransmit-счётчики пода (/proc/net/snmp) до/после. +Итог: таблица «локаль vs ВМ vs внутри пода» — что режет платформа, а что сервис. +