Files
loadtest/History/2026-08-21-stress-test-egress.md
T

2.3 KiB
Raw Blame History

2026-08-21 — LoadTest: стресс-тест egress (Flask тянет с ВМ) — результаты

Дата: 2026-08-21. Инстанс: http-12.containerk8s.dev.nubes.ru (k8s-4-sandbox), образ v2.0.2. Квота пода: CPU 100m, RAM 200MB, 1 реплика, gunicorn 1 worker (sync).

Сценарии и результаты

Сценарий Результат
Одиночный 1МБ / 10МБ 200 (0.2с / 0.9с)
Одиночный 50МБ 200 (5.3с)
Одиночный 100МБ 502 ~10с + health 502 → OOM (квота 200МБ)
Серия 30×1МБ 30/30 ok
Серия 10×10МБ 10/10 ok
Параллельно 5×1МБ 5/5 ok (сериализовано 1 worker'ом, 0.17-0.86с)
Долгий микс 50 (1МБ+10МБ) 50/50 ok, health стабилен 200
Повтор 3×50МБ 3/3 ok (~5.3с стабильно)
/fetch на несуществующий URL 200 от /fetch, status 404 от upstream (обработка ок)
/upload 1МБ (входной шлюз) HTTP 000 ~10с — входной шлюз по-прежнему режет >64КБ (ожидаемо)

Выводы

  1. Egress стабилен: 1МБ-50МБ тянутся надёжно, серии/миксы без сбоев, health держится.
  2. Ограничение — память пода: файл >~50-80МБ при квоте 200МБ → OOM → 502 (под перезапускается, потом health 200). Это НЕ проблема egress — это квота + r.content (весь файл в памяти).
  3. 1 worker (sync) — параллельные запросы сериализуются (не баг, а режим; для теста ок).
  4. Входной шлюз (>64КБ) НЕ обойдён для /upload — но схема «ВМ-буфер» его и не использует (браузер → ВМ, Flask тянет с ВМ по egress).

Рекомендации для прод-варианта

  • Поднять квоту памяти (например 1024МБ) ИЛИ потоковая передача (не r.content, а stream=True
    • чтение по частям) — уберёт OOM на 100МБ+.
  • При росте нагрузки — увеличить worker'ов gunicorn (сейчас 1).