Кратко и по делу — набор параметров и рекомендуемых значений/распределений для симуляции пользователей LMS, чтобы оценить пропускную способность, задержки и качество опыта.
1) Модель сессии и входящий поток
- Интенсивность входящих сессий: пуассонов поток с параметром $\lambda$ (пользователей/с): пример базовый $\lambda =0.5\text{users/s}$, пик $\lambda =5\text{users/s}$.
- Длительность сессии: тяжёлый хвост, логнормальное или парето: $\text{LogNormal}(\mu ,\sigma )$ с медианой $\approx 30\text{min}$ (пример: $\mu =\ln (1800),\sigma =0.8$). Можно также задать смесь коротких ($<5\text{min}$) и длительных ($>60\text{min}$) с вероятностями.
- Количество одновременных подключений/сессий на клиент: $1\text{–}6$ TCP коннектов, Вебсокет сессии удерживаются в течение всей сессии с вероятностью $p$.
2) Поведения внутри сессии (action mix)
- Доли типов действий (пример): просмотр каталога $20\%$, открытие страницы курса $30\%$, потоковое видео $25\%$, прохождение теста/отправка задания $5\%$, скачивание материалов $5\%$, форум/чат $10\%$, фоновые API-поллинги $5\%$. (Сумма $100\%$). Все числа в KaTeX: $20\%$, $30\%$ и т.д.
- Последовательность действий: переходная матрица/марковская модель между состояниями (например вероятность перехода с просмотра на видео $p=0.4$, на форум $p=0.1$, завершение сессии $p=0.2$).
3) Think-times / задержки между действиями
- Междейственные паузы (think time) для интерактивных страниц: распределение логнормальное или экспоненциальное, типичные значения: $3\text{–}15\text{s}$ для кликов/навигации; $30\text{–}180\text{s}$ для чтения/чтения лекции без видео.
- Для видео: время до следующего пользовательского действия (просмотр, перемотка) — длинный хвост, медиана $5\text{–}20\text{min}$.
- Поллинг / heartbeat: когда нет вебсокетов — поллинг каждые $15\text{–}60\text{s}$.
4) Сетевые параметры
- RTT распределение: пиковая локальная сеть $20\text{–}50\text{ms}$, мобильные/международные $50\text{–}200\text{ms}$. Моделировать как смесь дельта/экспоненциального.
- Каналная скорость клиента: распределение; пример медиана $5\text{Mbps}$, обрывы/флопы $<1\text{Mbps}$ для $10\%$ пользователей.
- Потери пакетов/сбоев: вероятность потери $p_{\text{loss}}\approx 0.1\%\text{–}2\%$.
5) Характеристики действий (нагрузка на сервер и сеть)
- Page load (HTML+assets): средний payload $50\text{–}800\text{kB}$ в зависимости от кеширования; время серверной обработки (CPU+DB) на endpoint: распределение $\text{Normal}$ или $\text{LogNormal}$ с медианой $50\text{–}300\text{ms}$.
- API запроса (AJAX): payload $1\text{–}10\text{kB}$, серверная обработка $20\text{–}150\text{ms}$.
- Видео: ABR профили битрейтов $\{0.5,1.5,3.0,5.0\}\text{Mbps}$ с вероятностями $\{10\%,40\%,40\%,10\%\}$. Чанк длиной $4\text{s}$ → размер чанка ~ битрейт×$4\text{s}$. Реквест на чанк каждые $4\text{s}$.
- Загрузки/выгрузки (assignments): средний файл $1\text{–}50\text{MB}$.
- Форум/чат: websocket-сообщения $0.1\text{–}2\text{msg/s}$ при активности.
6) Серверная внутренняя модель
- Время обработки на балансировщике/прокси $\sim 1\text{–}5\text{ms}$.
- Backend API: средние времена БД-запросов $5\text{–}200\text{ms}$ (с хвостом до $>1\text{s}$ для тяжёлых агрегаций).
- Кэш-хитрейт (CDN/Redis): настроить $H$ — доля запросов обслуживаемых кешем, пример $H=70\%$.
- Максимум соединений в БД/пуле: $N_{\text{db}}$ (влияет на очередь запросов и рост латентностей).
7) Повторы/ошибки
- Вероятность серверной ошибки $p_{5xx}=0.1\%\text{–}1\%$ (регионально выше при пиковых нагрузках).
- Модель ретраев: экспоненциальный бэкофф с параметром $\tau$ (например начальная задержка $200\text{ms}$, множитель $2$, максимум $3$ попытки).
8) Метрики, которые необходимо собирать и целевые пороги
- Пропускная способность (throughput): запросы/сек $\text{(req/s)}$, и трафик в битах/сек $\text{(Mbps)}$.
- Латентности: медиана $P_{50}$, $P_{90}$, $P_{95}$, $P_{99}$ для каждого типа операции (page load, API, video chunk). Примеры целевых порогов: $P_{95}(\text{page})<500\text{ms}$, $P_{99}(\text{page})<2\text{s}$, video startup $<3\text{s}$, rebuffering ratio $<1\%$.
- Апдейты пользовательского опыта: Apdex, где Apdex = $\frac{N_{\text{S}}+N_{\text{T}}/2}{N_{\text{total}}}$ (порог T — допустимое время, например $T=0.5\text{s}$).
- QoE для видео: startup delay, rebuffering events/мин, rebuffering ratio = $\frac{\text{rebuffer time}}{\text{play time}}$.
- Ошибки: процент 4xx/5xx запросов, процент таймаутов, процент неуспешных загрузок.
- Показатели инфраструктуры: CPU, память, диск IOPS, средняя длина очереди запросов, число открытых соединений, использование DB-пулов.
9) Сценарии тестирования
- Базовый рабочий: steady $\lambda$ в течение $30\text{min}$.
- Пиковая волна: линейный рост до пика за $10\text{min}$, удержание пика $20\text{min}$.
- Стресс: увеличение $\lambda$ пока $P_{95}$ не превысит целевой порог или ресурсы не исчерпаются.
- Soak/проверка на утечки: длительный запуск $24\text{h}$ при среднем трафике.
10) Как использовать результаты для оценки
- Определить $N_{\text{concurrent}}$ — максимальное число одновременных пользователей при соблюдении целевых $P_{95}$ и $p_{5xx}$.
- Плотность потребления ресурсов: сопоставить req/s и Mbps с метриками CPU/IO, найти узкие места (DB, сеть, CPU).
- Оценить tail-latency (особенно $P_{99}$) — критична для UX.
- Оценить видео QoE (startup + rebuffering) отдельно — это ключ для пользовательского удержания.
Резюме (набор параметров для симулятора — минимальный набор):
- входной поток: $\lambda$ (users/s), с пиками;
- сессионная длительность: логнормальная (медиана $\approx 30\text{min}$);
- action mix и переходные вероятности;
- think-times на действие: распределения и параметры (например $3\text{–}15\text{s}$);
- payload/bitrate для каждого действия (page size, video bitrate chunks);
- сетевые RTT/throughput распределения;
- серверные время обработки по endpoint;
- кеш-хитрейт $H$, p ошибок и модель ретраев;
- метрики: req/s, Mbps, $P_{50},P_{90},P_{95},P_{99}$, Apdex, video QoE.
Если нужно — могу дать конкретный JSON/пример конфига для симулятора (Gatling/k6/Locust) с указанными распределениями и значениями.