# 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).