Files
loadtest/History/diag-2026-08-18-compare-clusters.md

2.1 KiB
Raw Permalink Blame History

Сравнение замеров: iot-naeel vs общий кластер (k8s-4-sandbox-nubes-ru)

Дата: 2026-08-18. LoadTest loadtest.pythonk8s.dev.nubes.ru. Редеплой на общий кластер: 18.08.2026 09:19-09:21 (Тазетдинов Н.Ф.), realm k8s-4-sandbox-nubes-ru.

Результат: тот же внешний шлюз, но разный исход

Размер тела iot-naeel общий кластер
1-64 КБ быстро (0.2-0.4 с), 200 быстро (0.2-0.4 с), 200
68-512 КБ задержка ~51.5 с, но 200 обрыв HTTP 000 через ~10.2 с

/messages по размерам (общий кластер, 3 ретрая)

  • 1/32/64 КБ: 200, 0.22-0.43 с (всегда ок)
  • 68 КБ: 000(10.2) / 200(0.39) / 000(10.2)
  • 72 КБ: 200(0.39) / 000(10.2) / 000(10.2)
  • 84 КБ: 200(0.43) / 000(10.2) / 000(10.2)
  • 100 КБ: 000(10.2) x3 (+ ещё 4 из 5 = 000, 1 из 5 = 200)
  • 128 КБ: 000 / 200(0.56) / 000
  • 256 КБ: 000 / 200(0.91) / 000

/upload (файлы), 1 МБ (общий кластер)

  • 000(10.2) / 200(2.89) / 200(2.87) — тоже случайные обрывы.

Тайминг обрыва (100 КБ, общий кластер)

http=000 connect=0.0007s TLS=0.13s TTFB=0.000s total=10.22s → соединение+TLS есть, сервер НЕ начал отвечать (TTFB=0), обрыв ~10.2 с на передаче тела.

Вывод

Механизм единый: внешний шлюз/балансировщик платформы перехватывает тела >~64-68 КБ.

  • iot-naeel: шлюз держит ~50 с и пропускает (200, но с задержкой ~51 с).
  • общий кластер (k8s-4-sandbox): шлюз ОБРЫВАЕТ через ~10 с → HTTP 000 → «не грузится». Внутри кластера на iot-naeel сервер/сеть мгновенные (100КБ=0.11-0.18с, 10МБ=0.20с) → это НЕ приложение/Flask/сеть кластера. Вероятность прохода на общем кластере ~1 из 3 (случайно).