Как мы тестируем QoE приложений: время транзакции у пользователя

Канал филиала прошел приемку: 1 Gbps, ноль потерь, задержка в рамках договора. В понедельник страница CRM в филиале открывается 4 секунды, и в заявке написано «сеть тормозит». Правы обе стороны: на приемке тестовые потоки шли по пустому каналу, а пользователь открывает страницу из 80 объектов по HTTPS через прокси, пока бэкап заполняет тот же канал. Мы измеряем, сколько ждет каждый эмулированный пользователь, транзакцию за транзакцией, при включенном остальном трафике.

Стенд

Путь собирается на стенде CloudLAB так, как работает в продакшене: маршрутизатор филиала или SD-WAN edge, NGFW или прокси с вашей политикой, точка доступа Wi-Fi, WAN-канал. WANemu задает каналу задержку, jitter, потери и ограничение полосы в каждом направлении по измеренному профилю вашего провайдера. На дальней стороне стенд эмулирует серверы: веб-страницы со множеством объектов, SaaS-подобные API поверх TLS, файловые ресурсы, почту, DNS. Они отвечают за фиксированное время, поэтому каждая миллисекунда, которая меняется от прогона к прогону, приходится на путь.

У каждого эмулированного пользователя свой адрес, свои DNS-запросы, сессии TCP и TLS и пауза между кликами, и каждый выполняет сценарий реальных транзакций: страница, вызов API, скачивание и загрузка файла, письмо. Состав пользователей и доля bulk-трафика (бэкапы, обновления, видео) берутся из вашего NetFlow или из библиотеки приложений нашего генератора трафика.

Что проверяем

• Время у пользователя для каждого типа транзакций: p50, p95 и p99 по всем пользователям против цели, согласованной до прогона
• Фазы: DNS-запрос, TCP и TLS handshake, time to first byte, передача, чтобы у медленной секунды был адрес
• Сбои: таймауты, сбросы, ошибки HTTP, ответ 200 со страницей ошибки или блокировки внутри
• Goodput на пользователя и то, насколько ровно делится канал, когда файлы тянут многие сразу
• Bulk-трафик: бэкап заполняет канал; интерактивные транзакции замеряются до, во время и после, с QoS и без
• Расстояние: те же сценарии при задержке, jitter и потерях каждого типа филиала и RTT, при котором транзакция выходит за цель
• Функции на пути: TLS inspection, URL-фильтрация, контроль приложений, аутентификация на прокси включаются по одной, с миллисекундами, которые добавляет каждая
• Число пользователей: ступени до численности самой большой площадки и ступень, на которой p95 выходит из коридора

Throughput остается в отчете как контекст, вердикт пишется в терминах пользователя, например «страница CRM при p95 до 2 с для 300 пользователей в филиале за 60 мс».

Что обычно ломается

Обмены туда и обратно. В типичном проекте страница CRM открывается за 1 с в головном офисе и за 4 с в филиале в 60 мс от него, при загрузке канала на пятую часть (числа для примера). Страница делает около 50 последовательных обменов: DNS для нескольких хостов, редирект, TLS через прокси, объекты по нескольку за раз. 50 × 60 мс дают 3 с, и более широкий канал ни один из них не убирает. Когда обмены посчитаны по каждой транзакции, исправление уходит в приложение или прокси, а договор на расширение канала остается неподписанным.

Очередь. Дневной бэкап заполняет буфер WAN edge, и RTT под ним растет с 20 до 200 мс (пример). Каждый из тех же 50 обменов стоит в 10 раз дороже, p95 страницы переходит за 10 с, а средняя загрузка канала выглядит здоровой. Класс QoS или шейпер с короткой очередью возвращают прежнюю картину; мы замеряем до и после, как в наших тестах QoS.

Инспекция в час пик. С включенной TLS inspection на firewall у каждого соединения два handshake: до него и от него. В 9:00, когда сотни пользователей логинятся разом, устройство подходит к пределу по handshake, и фаза TLS у части пользователей растет с десятков миллисекунд до секунды и больше. Среднее это прячет, p99 показывает. DNS ломается так же тихо: резолвер филиала под нагрузкой теряет запросы, и клиент ждет повтора от 1 до 5 с, еще до начала загрузки страницы.

Что в отчете

По каждому типу транзакций: p50, p95 и p99 по пользователям для каждой ступени, профиля деградации и набора функций, с разбивкой по фазам. Сбои по причинам, goodput на пользователя, те же таблицы с bulk-трафиком и без него. Сценарии, паузы, веса в миксе и настройки эмулятора, чтобы прогон повторился после исправления или с конкурирующим устройством.

С чего начать

Пришлите нам приложения, на которые жалуются пользователи, площадки, с которых они работают, и то, что стоит на пути. Мы ответим черновиком тест-плана: пункты проверки, схема стенда и сроки. Отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.