3.1 KiB
Сессия 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 с; на общем кластере с меньшим таймаутом он, вероятно, ДАЁТ ОБРЫВ до ответа → «не грузится».
Решения / что дальше
- Дождаться редеплоя нагрузки на общий кластер и повторить замеры там.
- Если на общем кластере ошибка — сравнить http-код и время, подтвердить обрыв на том же шлюзе.
- Возможный обход: чанковая передача (как в contracts-saga) для гарантированного прохода.
Результаты сохранены
History/diag-2026-08-18-msg-delay.md(замеры, тайминги, внутрикластерные тесты) — запушено9e201a3.