# 🚀 RUSEON Core — Результаты нагрузочного тестирования / Load Test Results

> **Дата тестирования / Timestamp:** `2026-08-23 17:21:14` | **Длительность / Duration:** `28800.1 сек / 28800.1 s` | **CPU Cores:** `12`

---

## 🇷🇺 Отчет на русском языке

> ⚠️ **In-process benchmark:** REST API и HLS latency измеряются через `httptest.Server` loopback (сетевой RTT не включён). WebRTC WHEP использует реальный стек Pion P2P.

### ⚙️ Конфигурация нагрузки

| Параметр | Значение | Описание |
| :--- | :--- | :--- |
| **Синтетические камеры** | `600` | Входящие потоки 30 FPS (~2.5 Mbps каждый) |
| **HLS fMP4 Зрители** | `1800` | Клиенты, выкачивающие манифесты и видеосегменты |
| **WebRTC WHEP Клиенты** | `240` | Клиенты с SDP-хендшейком и приемом RTP видео |
| **REST API Воркеры** | `10` | Параллельные запросы к роутеру Gin (с JWT авторизацией) |
| **gRPC AI Воркеры** | `20` | Двунаправленный gRPC стриминг метаданных и кадров |
| **Реальный диск (MP4)** | `false` | Запись видеоархива через `pkg/storage/localfs` |

### 📊 Ключевые показатели производительности

| Компонент | Метрика | Значение | Латентность p50 / p95 / p99 |
| :--- | :--- | :--- | :--- |
| **Ingest (RTSP/NALU)** | Суммарный FPS | **18180 FPS** (1342.9 Mbps) | — (Drops: `0`) |
| **REST API** | Throughput / RPS | **460 RPS** (OK: `13244819`, Err: `0`) | `0.59 ms` / `8.52 ms` / `28.74 ms` |
| **HLS fMP4 Delivery** | Отдано сегментов | **17625404 seg** (501.9 MB/s) | `3.59 ms` / `211.22 ms` / `442.35 ms` |
| **WebRTC WHEP** | RTP Пакетов | **2439152 pkts** (0.1 MB/s) | Handshake: `390.26 ms` / `935.41 ms` |
| **gRPC Stream & AI** | Кадров / Метаданных | **18180 FPS** / **1993 RPS** | Stream: `28.45 ms` (Err: `0`) |
| **EventBus Webhooks** | Published / Delivered / Dropped | **11042761** / **11042761** / **0** (0.0%) | — |

### 🖥️ Потребление системных ресурсов

| Ресурс | Значение |
| :--- | :--- |
| **Активные горутины** | `348` |
| **Heap Alloc / In-Use** | `95 MB` / `135 MB` |
| **System Memory (Sys)** | `2595 MB` |
| **RSS (Реальная память процесса)** | `707 MB` |
| **CPU System (avg / peak)** | `52.4%` / `98.1%` |
| **Process CPU Usage** | `311.7%` |
| **Network RX / TX (OS)** | `5635.4 Mbps` / `38.6 Mbps` |
| **GC Cycles / Pause Total** | `154969 циклов` / `159497.06 ms` (Max pause: `7.69 ms`) |

### 💡 Инженерные примечания и продакшен-рекомендации

1. **WebRTC WHEP Handshake (~140–180 ms):**
   * В бенчмарке замеряется полный Non-Trickle хендшейк со сбором сетевых интерфейсов ОС. В веб-браузерах с поддержкой Trickle ICE отклик видео наступает мгновенно (<50 ms).
   * Все соединения мультиплексируются через единый порт `8555/UDP` (UDP Muxer), исключая необходимость проброса сотен портов в Firewall.
2. **HLS Латенси плейлистов (First-Segment vs Polling):**
   * **Задержка первого сегмента (≤ 2 сек / 1 GOP):** При холодном старте первого зрителя (`lazyHLS=true`) муксер ожидает прихода первого ключевого кадра (I-Frame) и формирования первого видеосегмента. Время ожидания первого плейлиста составляет до 1–2 секунд (длительность одного GOP). **Это штатная архитектурная логика HLS (не баг)**, гарантирующая, что клиент получит валидный воспроизводимый плейлист с готовым видеосегментом.
   * **Последующий опрос (Polling Latency p50 < 1 ms):** Как только первый сегмент готов, все последующие обновления плейлиста и запросы от сотен клиентов отдаются мгновенно из памяти с латентностью `p50 < 1 ms` и `Zero-Alloc`.
3. **Дисковая подсистема (30 MB/s на 100 камер):**
   * Для 100+ камер с непрерывной MP4 записью рекомендуется использовать NVMe/SATA SSD или RAID-массивы для предотвращения деградации IOPS при параллельной очистке старого архива (`CleanupTask`).
4. **Защита ядра от медленных клиентов (Slow Consumers):**
   * Изолированные кольцевые буферы (`RingBuffer`) сбрасывают устаревшие кадры только для отстающих клиентов, предотвращая накопление очереди в оперативной памяти и не затрагивая других зрителей.
5. **AI & gRPC Интеграция:**
   * Канал передачи кадров в нейросети выдерживает 3 000+ FPS. При высокой вычислительной нагрузке на GPU рекомендуется настраивать частоту инференса на уровне 5–10 FPS на камеру.
6. **Безопасность и WebRTC:**
   * Для воспроизведения WebRTC в современных браузерах (Chrome, Safari, Firefox) требуется развертывание с HTTPS/TLS сертификатом (Secure Context).

---

## 🇬🇧 English Report

> ⚠️ **In-process benchmark:** REST API and HLS latency are measured via `httptest.Server` loopback (network RTT not included). WebRTC WHEP uses real Pion P2P stack.

### ⚙️ Load Configuration

| Parameter | Value | Description |
| :--- | :--- | :--- |
| **Synthetic Cameras** | `600` | Ingest streams @ 30 FPS (~2.5 Mbps each) |
| **HLS fMP4 Viewers** | `1800` | Clients continuously fetching playlists and video segments |
| **WebRTC WHEP Clients** | `240` | Clients with SDP handshake and RTP video reception |
| **REST API Workers** | `10` | Concurrent requests to Gin router (with JWT auth) |
| **gRPC AI Workers** | `20` | Bidirectional gRPC streaming for frames and metadata |
| **Real Disk (MP4)** | `false` | Video archive recording via `pkg/storage/localfs` |

### 📊 Key Performance Metrics

| Component | Metric | Value | Latency p50 / p95 / p99 |
| :--- | :--- | :--- | :--- |
| **Ingest (RTSP/NALU)** | Total FPS | **18180 FPS** (1342.9 Mbps) | — (Drops: `0`) |
| **REST API** | Throughput / RPS | **460 RPS** (OK: `13244819`, Err: `0`) | `0.59 ms` / `8.52 ms` / `28.74 ms` |
| **HLS fMP4 Delivery** | Delivered Segments | **17625404 seg** (501.9 MB/s) | `3.59 ms` / `211.22 ms` / `442.35 ms` |
| **WebRTC WHEP** | RTP Packets | **2439152 pkts** (0.1 MB/s) | Handshake: `390.26 ms` / `935.41 ms` |
| **gRPC Stream & AI** | Frames / Metadata | **18180 FPS** / **1993 RPS** | Stream: `28.45 ms` (Err: `0`) |
| **EventBus Webhooks** | Published / Delivered / Dropped | **11042761** / **11042761** / **0** (0.0%) | — |

### 🖥️ System Resource Consumption

| Resource | Value |
| :--- | :--- |
| **Active Goroutines** | `348` |
| **Heap Alloc / In-Use** | `95 MB` / `135 MB` |
| **System Memory (Sys)** | `2595 MB` |
| **Process RSS Memory** | `707 MB` |
| **System CPU (avg / peak)** | `52.4%` / `98.1%` |
| **Process CPU Usage** | `311.7%` |
| **Network RX / TX (OS)** | `5635.4 Mbps` / `38.6 Mbps` |
| **GC Cycles / Pause Total** | `154969 cycles` / `159497.06 ms` (Max pause: `7.69 ms`) |

### 💡 Engineering Notes & Production Recommendations

1. **WebRTC WHEP Handshake (~140–180 ms):**
   * Measures complete Non-Trickle ICE handshake including OS network interface gathering. In browsers supporting Trickle ICE, video starts even faster (<50 ms).
   * All peer connections are multiplexed over a single `8555/UDP` port (UDP Muxer), eliminating the need to expose large port ranges in Firewalls.
2. **HLS Playlist Latency (First-Segment vs Steady-State Polling):**
   * **First-Segment Startup Latency (≤ 2 s / 1 GOP):** On cold start for the first viewer (`lazyHLS=true`), the HLS muxer waits for the first keyframe (I-Frame) to arrive and generate the initial playable segment. First playlist response latency takes up to 1–2 seconds (the duration of one GOP). **This is by design and architectural logic (not a bug)**, ensuring that HLS video players receive a valid, ready-to-play manifest with actual media.
   * **Steady-State Polling Latency (p50 < 1 ms):** Once the initial segment is produced, all subsequent playlist updates and polling requests across hundreds of concurrent viewers are served directly from in-memory ring cache with ultra-low latency (`p50 < 1 ms`) and Zero-Alloc performance.
3. **Storage Subsystem (30 MB/s per 100 cameras):**
   * For 100+ cameras with continuous MP4 recording, NVMe/SATA SSDs or RAID arrays are recommended to prevent IOPS degradation during background archive retention cleanup (`CleanupTask`).
4. **Core Protection Against Slow Consumers:**
   * Isolated per-stream ring buffers (`RingBuffer`) drop outdated frames only for lagging clients, preventing memory queue buildup and zero-copy stability for other viewers.
5. **AI & gRPC Integration:**
   * The frame extraction channel easily sustains 3,000+ FPS. For compute-heavy GPU inference, frame subsampling (5–10 FPS per stream) is advised.
6. **Security & WebRTC:**
   * Modern web browsers (Chrome, Safari, Firefox) require HTTPS/TLS (Secure Context) to initiate WebRTC sessions.

---
*Report automatically generated by `cmd/loadtest`.*