Тестирование системы
Метрики, стандарты, инструменты и методология нагрузочного тестирования телефонной системы. От измерения CPS и MOS до планирования ёмкости по формуле Эрланга.
Метрики телефонной системы
Телефонная система отличается от веб-приложений: здесь важно не время ответа на HTTP-запрос, а качество голоса в реальном времени. Три категории метрик: нагрузка, качество и надёжность.
Что мы измеряем │ ├─ Нагрузка │ ├─ CPS (Calls Per Second) │ ├─ Concurrent Calls │ └─ BHT (Busy Hour Traffic) │ ├─ Качество │ ├─ MOS (Mean Opinion Score) │ ├─ Jitter │ ├─ Latency │ └─ Packet Loss │ └─ Надёжность ├─ ASR (Answer Seizure Ratio) ├─ PDD (Post Dial Delay) ├─ Uptime └─ Failover Time
| Метрика | Описание | Хорошо | Плохо |
|---|---|---|---|
| CPS | Calls Per Second — сколько новых вызовов в секунду принимает система | >50 | <10 |
| Concurrent | Количество одновременных активных вызовов | по плану | CPU >80% |
| PDD | Post Dial Delay — время от набора до начала звонка (гудков) | <3 сек | >8 сек |
| MOS | Mean Opinion Score — субъективная оценка качества голоса (шкала 1–5) | >4.0 | <3.5 |
| ASR | Answer Seizure Ratio — процент успешных соединений | >50% | <30% |
| Jitter | Вариация задержки между пакетами (нестабильность) | <30 мс | >50 мс |
| Latency | Односторонняя задержка передачи голоса | <150 мс | >300 мс |
| Packet Loss | Процент потерянных пакетов | <1% | >3% |
| BHT | Busy Hour Traffic — нагрузка в час пик, измеряется в Эрлангах | расчётное | — |
MOS 4.0 — это «хорошо, как стационарный телефон». MOS 3.5 — «приемлемо, но слышны артефакты». Ниже 3.0 — пользователи будут жаловаться. G.711 без потерь даёт MOS ~4.4, Opus — до 4.9.
Стандарты и регламенты
Метрики телефонии определены международными стандартами. Эти документы описывают что измерять, как измерять и какие значения считать приемлемыми.
| Стандарт | Организация | Описание |
|---|---|---|
| RFC 6076 | IETF | SIP Performance Metrics — определяет PDD, SRD (Session Request Delay), SDD (Session Disconnect Delay) |
| ITU-T G.107 | ITU | E-model — математическая модель расчёта качества голоса. Вычисляет R-фактор, из которого получается MOS |
| ITU-T P.800 | ITU | Методология MOS — как проводить субъективное тестирование качества голоса с участием людей |
| ITU-T P.862 | ITU | PESQ (Perceptual Evaluation of Speech Quality) — автоматическое измерение MOS без участия людей |
| ITU-T P.863 | ITU | POLQA (Perceptual Objective Listening Quality Analysis) — следующее поколение PESQ, поддерживает HD Voice |
| ITU-T Y.1540 | ITU | Параметры качества IP-сетей: допустимые задержки, потери пакетов, джиттер |
| ITU-T E.500 | ITU | Интенсивность трафика, формула Эрланга, Grade of Service (GoS) |
E-model (G.107) вычисляет R-фактор (0–100) на основе задержки, джиттера, потерь и кодека. R-фактор конвертируется в MOS: R>90 → MOS>4.3 (отлично), R=70–80 → MOS 3.5–4.0 (приемлемо), R<60 → MOS<3.1 (плохо).
SIPp — нагрузочное тестирование
SIPp — open-source инструмент для генерации SIP-трафика. Имитирует тысячи виртуальных телефонов, отправляет INVITE-сообщения, принимает ответы и генерирует RTP-трафик. Позволяет найти пределы системы до того, как это сделают реальные пользователи.
SIPp (генератор нагрузки) Тестируемая система ┌─────────────────────────┐ ┌─────────────────────┐ │ │ │ │ │ Имитирует 1000 │ ── INVITE ──> │ Kamailio / FS │ │ виртуальных телефонов │ │ │ │ │ <── 100 ──── │ Обрабатывает │ │ Отправляет SIP INVITE │ <── 200 OK ─ │ маршрутизирует │ │ × 1000 │ │ отвечает │ │ │ ──── ACK ──> │ │ │ Генерирует RTP │ │ │ │ (имитация голоса) │ ══ RTP ════> │ Медиа-обработка │ │ │ │ │ └─────────────────────────┘ └─────────────────────┘ │ ▼ Результаты: ├─ CPS: 47 calls/sec ├─ Max concurrent: 412 ├─ PDD avg: 120ms ├─ Failed: 0.2% └─ Retransmissions: 15
-sn uac — встроенный сценарий клиента (звонящий)
-d — длительность каждого звонка (мс)
-l — лимит одновременных вызовов
-r — скорость генерации (calls per second)
-rtp_echo — генерировать RTP-поток
— Имитировать тысячи SIP-телефонов
— Использовать пользовательские XML-сценарии
— Генерировать RTP-трафик
— Записывать детальную статистику в CSV
— Вставлять переменные (номера, пароли) из CSV-файла
— Работать как UAS (сервер) и UAC (клиент)
Пример XML-сценария SIPp (пользовательский)
Четыре типа нагрузочных тестов
Цель: найти максимальную ёмкость системы.
Постепенно увеличиваем нагрузку, пока система не начнёт отказывать. Ответ: «наша система держит максимум 500 concurrent».
Нагрузка ▲ │ ╱ ← отказ │ ╱ │ ╱ │ ╱ │╱ └──────────▶ Время
Цель: проверить стабильность под длительной нагрузкой.
24–72 часа работы при 70% от максимума. Ищем: утечки памяти, деградацию производительности, зависания.
Нагрузка
▲
│ ═══════════════════ 70%
│
│
│
└──────────────────▶ Время
24-72 часа
Цель: проверить реакцию на внезапный всплеск нагрузки.
Резкий пиковый всплеск нагрузки. Ответ: «система восстанавливается за 3 секунды».
Нагрузка ▲ ╱╲ │ ╱ ╲ ╱╲ │═╱════╲═════╱══╲═ │ └──────────────────▶ Время
Цель: определить сколько серверов нужно для целевой нагрузки.
Вопрос: сколько серверов для 10 000 concurrent calls? Решение: формула Эрланга + результаты ramp test.
Серверы ▲ │ ● 10k calls │ ● │ ● │● └──────────────────▶ Нагрузка
SIPp должен работать на отдельной машине от тестируемой системы. Иначе генератор нагрузки будет конкурировать с системой за CPU и результаты будут искажены.
Формула Эрланга — расчёт ёмкости
1 Эрланг = один канал, занятый 100% времени (60 минут из 60). Если оператор разговаривает 45 минут в час, его нагрузка = 45/60 = 0.75 Эрланга. Формула Эрланга B рассчитывает, сколько каналов нужно для заданной нагрузки с допустимой вероятностью блокировки.
Задача: клиент имеет 400 операторов колл-центра. В час пик каждый разговаривает ~45 минут из 60. Сколько каналов (concurrent calls) нужно?
FreeSWITCH: 1 CPU core ≈ 50–80 concurrent (с транскодингом) или 200–300 concurrent (без транскодинга). Для 384 concurrent нужно: ~2 сервера FreeSWITCH (или 1 мощный с 8+ ядрами).
Расчёт ёмкости: 400 операторов × 45 мин/час = 300 Эрланг │ Erlang B (P=1%) │ ▼ 320 каналов + 20% = 384 concurrent │ ┌──────────┴──────────┐ │ │ С транскодингом Без транскодинга 50-80 per core 200-300 per core ≈ 5-8 ядер ≈ 2 ядра
Подробнее о формуле Эрланга B
Формула Эрланга B (Erlang B):
B(N, A) = (A^N / N!) / Σ(k=0..N) (A^k / k!)
Где:
— N — количество каналов (линий)
— A — предлагаемая нагрузка в Эрлангах
— B — вероятность блокировки (Grade of Service)
На практике используют таблицы Эрланга или онлайн-калькуляторы, а не считают вручную. Стандартный GoS для бизнеса — 1% (P.01), для экстренных служб — 0.1% (P.001).
Инструменты тестирования
| Инструмент | Назначение | Бесплатный |
|---|---|---|
| SIPp | Нагрузочное SIP-тестирование — генерация вызовов, измерение CPS и concurrent | Да |
| Homer + HEP | SIP-трафик capture и анализ — визуализация SIP-диалогов, поиск ошибок | Да |
| VoIPmonitor | Мониторинг качества голоса в реальном времени — MOS, jitter, потери пакетов | Community |
| Grafana + Prometheus | Дашборды мониторинга — CPU, память, количество каналов, тренды нагрузки | Да |
| SRTP Tester | Тестирование шифрования медиа — проверка корректности SRTP/DTLS | Да |
| Opalvoip | SIP-бенчмарки — альтернатива SIPp для специфичных сценариев | Да |
| Twilio SIP Test | Тестирование совместимости SIP-транков — проверка подключения к провайдерам | Бесплатный |
Homer перехватывает SIP-пакеты через HEP-протокол и визуализирует их как ladder-диаграммы. Видно каждый SIP-заголовок, каждый ответ, каждую ошибку. Незаменим для отладки проблем с маршрутизацией и регистрацией.
Пассивно слушает RTP-потоки и рассчитывает MOS для каждого звонка в реальном времени. Показывает джиттер, потери, задержку. Сигнализирует, когда качество падает ниже порога. Интегрируется с Grafana.
Рекомендуемая связка: SIPp (нагрузочные тесты перед релизом) + Homer (SIP-отладка) + VoIPmonitor (качество голоса) + Grafana/Prometheus (системные метрики). Все инструменты бесплатны и open-source.
План тестирования нашей системы
Этот план выполняется на Фазе 2 (когда готовы Go API + ESL) и повторяется перед каждым значимым релизом. Цель — получить конкретные числа: «система держит X concurrent при MOS >4.0 и PDD <3 сек».
Финальный отчёт тестирования: ┌────────────────────────────────────────┐ │ Система: Kamailio + FreeSWITCH │ │ Сервер: 8 vCPU, 16 GB RAM │ │ │ │ Max CPS: 47 calls/sec │ │ Max Concurrent: 412 calls │ │ PDD avg: 120 ms │ │ MOS avg: 4.2 │ │ Failed: 0.2% │ │ │ │ Вердикт: система готова к продакшену │ │ при нагрузке до 300 concurrent │ └────────────────────────────────────────┘
Запускайте нагрузочные тесты перед каждым релизом, после обновления FreeSWITCH или Kamailio, при изменении конфигурации кодеков или маршрутизации. Автоматизируйте через CI/CD.