# Диагностика задержки приёма сообщений > ~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 без браузера даёт то же).