3.3 KiB
3.3 KiB
Диагностика задержки приёма сообщений > ~64-68KB — внешний шлюз платформы
Дата: 2026-08-18. Стенд: ТЕСТ, iot-naeel, loadtest bb9ed30b-1794-44ff-81a2-6ff2731200c9.
Симптом
- Сообщения 1-64 КБ через
POST /messagesпринимаются быстро (~0.2-0.4 с). - 68 КБ и выше — фиксированная задержка ~51.4-51.9 с, но в итоге HTTP 200.
- Зона ~64-84 КБ — случайный порог: то быстро, то 51 с.
Замеры /messages (внешний URL, curl, 3 ретрая)
| Размер | res |
|---|---|
| 1 КБ | 0.23-0.32 с (3x) |
| 8/32/48 КБ | 0.25-0.35 с |
| 64 КБ | 0.40-0.41 с |
| 68 КБ | 51.4 с (3x) |
| 72 КБ | 51.4-51.5 с (3x) |
| 84 КБ | 51.5 / 0.58 / 51.5 |
| 100 КБ | 51.4-51.5 с (3x) |
| 128 КБ | 51.5-51.9 с |
| 256 КБ | 51.7-51.9 с |
| 512 КБ | 51.8-52.3 с |
Задержка ~51 с не зависит от размера (128 КБ ~ 512 КБ = одинаково) → это фиксированная пауза, а не «пропорционально объёму».
Большие payload через внешний URL (/messages)
| Размер | time | speed |
|---|---|---|
| 1 МБ | 52.1 с | 20 КБ/с |
| 10 МБ | 61.7 с | 170 КБ/с |
| 50 МБ | 102.5 с | 512 КБ/с |
Модель: ~51.5 с (фикс. задержка внешнего шлюза на старте для тел >~64КБ) + реальное время передачи. 1МБ=51.5+0.5; 10МБ=51.5+10; 50МБ=51.5+51.
Тайминги curl (100 КБ)
- DNS 0.00003 с, connect 0.0017 с, TLS 0.23 с, starttransfer (TTFB) 51.5 с.
Тесты внутри кластера (kubectl exec с ВМ remote-dev) — 100 КБ
| Путь | Время |
|---|---|
| localhost :5000 (в поде) | 0.11 с |
| ClusterIP 10.109.26.82:80 | 0.18 с |
| прямой IP пода 172.16.3.81:5000 | 0.09 с |
| внешний URL | 51.5 с |
Примечание: имя pythonk8s:5000 изнутри НЕ работает (Connection timed out) —
правильно pythonk8s:80 (ClusterIP, порт 80 → endpoint :5000).
Вывод
- Сервер (Flask), кластерная сеть, ClusterIP/kube-proxy, service — быстрые (100 КБ ≤ 0.18 с).
- 10 МБ внутри пода (localhost) = 0.20 с — сервер мгновенный даже для 10 МБ.
- ~51 с добавляет ВНЕШНИЙ шлюз/балансировщик платформы на входе в кластер.
- Он буферизует/придерживает крупное тело (~>64-68 КБ) фиксированные ~50 с, затем пропускает (200).
- На общем кластере (с меньшим таймаутом) тот же механизм, видимо, даёт ОБРЫВ до ответа → ошибка «не грузится».
- Не приложение/не Flask/не кластерная сеть. Гипотеза пользователя про «буферизацию» подтверждается на уровне внешнего шлюза (занимает буфер/ресурс на ~50 с), НО не в браузере (curl без браузера даёт то же).