Docs: сессия 2026-08-18 — задержка /messages, вывод про внешний шлюз
This commit is contained in:
@@ -0,0 +1,45 @@
|
|||||||
|
# Сессия 2026-08-18 — Диагностика задержки приёма сообщений /messages
|
||||||
|
|
||||||
|
_Стенд: ТЕСТ, iot-naeel. LoadTest `loadtest.pythonk8s.dev.nubes.ru` (instanceUid
|
||||||
|
`bb9ed30b-1794-44ff-81a2-6ff2731200c9`). k8s-доступ только через ВМ `ssh remote-dev`._
|
||||||
|
|
||||||
|
## Контекст
|
||||||
|
- LoadTest расширен: помимо загрузки файлов добавлен `POST /messages` (сырое тело,
|
||||||
|
случайное содержимое заданного размера) — v2.0.0.
|
||||||
|
- Цель: выяснить, почему на общем кластере сообщения >~50-64КБ не грузятся,
|
||||||
|
а на iot-naeel грузятся, но медленно.
|
||||||
|
|
||||||
|
## Гипотеза пользователя
|
||||||
|
«Данные буферизуются где-то (браузер/сервис), занимают ресурсы, но уже не нужны?»
|
||||||
|
→ Проверено. В БРАУЗЕРЕ НЕТ: прямой curl без браузера даёт ту же задержку (~51.5 с).
|
||||||
|
|
||||||
|
## Подтверждённый факт: НЕ приложение, НЕ Flask, НЕ кластерная сеть
|
||||||
|
Внутри кластера (kubectl exec, python в поде) — ВСЁ мгновенно:
|
||||||
|
- 100 КБ localhost:5000 = 0.11 с; ClusterIP 10.109.26.82:80 = 0.18 с; IP пода = 0.09 с;
|
||||||
|
- 10 МБ localhost = 0.20 с.
|
||||||
|
|
||||||
|
На внешнем URL `loadtest.pythonk8s.dev.nubes.ru`:
|
||||||
|
- 100 КБ = 51.5 с (200), 10 МБ = 61.7 с, 50 МБ = 102.5 с.
|
||||||
|
|
||||||
|
→ Ровно ~51 с добавляет ВНЕШНИЙ ШЛЮЗ/БАЛАНСИРОВЩИК платформы на входе в кластер
|
||||||
|
для тел крупнее ~64-68 КБ. Фиксированная пауза ~50 с (не пропорционально размеру).
|
||||||
|
|
||||||
|
## Ступенчатый порог (случайный в зоне 64-84 КБ)
|
||||||
|
| Размер | быстр/медл |
|
||||||
|
|---|---|
|
||||||
|
| 1-64 КБ | быстро (0.2-0.4 с) |
|
||||||
|
| 68 КБ | медленно 51.4 с (3x) |
|
||||||
|
| 72 КБ | медленно 51.4-51.5 (3x) |
|
||||||
|
| 84 КБ | 51.5 / 0.58 / 51.5 (случайно) |
|
||||||
|
| 100-512 КБ | 51.4-52 с |
|
||||||
|
|
||||||
|
Вывод: это не «лимит размера», а таймаут-механизм внешнего шлюза, упирающийся в ~50 с;
|
||||||
|
на общем кластере с меньшим таймаутом он, вероятно, ДАЁТ ОБРЫВ до ответа → «не грузится».
|
||||||
|
|
||||||
|
## Решения / что дальше
|
||||||
|
1. Дождаться редеплоя нагрузки на общий кластер и повторить замеры там.
|
||||||
|
2. Если на общем кластере ошибка — сравнить http-код и время, подтвердить обрыв на том же шлюзе.
|
||||||
|
3. Возможный обход: чанковая передача (как в contracts-saga) для гарантированного прохода.
|
||||||
|
|
||||||
|
## Результаты сохранены
|
||||||
|
- `History/diag-2026-08-18-msg-delay.md` (замеры, тайминги, внутрикластерные тесты) — запушено `9e201a3`.
|
||||||
Reference in New Issue
Block a user