Почему усредненные тесты врут: математические методы в нагрузочном тестировании

Нагрузочное тестирование редко бывает точным, если опираться только на «средние» показатели. Рассказываем, как избежать ошибок и даем практические приемы математического моделирования профиля нагрузки: от анализа дисперсий и корреляций до выявления парадокса Симпсона и финальной проверки модели.

Когда компания переходит на новую систему — будь то миграция с SAP на 1С или смена архитектуры базы данных, — первый вопрос, который звучит на совещании от IT-директора, почти всегда один и тот же: «А она выдержит?»

Этот вопрос звучит просто, но за ним скрывается целая цепочка неизвестных. Мы можем показать успешные кейсы: «Вот у нас был похожий проект — пять тысяч пользователей, всё работало». Но, как правило, это слабый аргумент. Одна система стояла у фармкомпании, другая — у угольного холдинга. Нагрузочные профили у них совершенно разные, и прямая аналогия здесь не работает.

Именно в этот момент на помощь приходит нагрузочное тестирование. Однако нагрузочное тестирование должно учесть полный цикла работы предприятия, работу в сезонность, пиковые часы и размерность операций. Для всего этого мы используем математические методы моделирования профиля нагрузки — подход, который позволяет не гадать, «потянет или не потянет», а заранее просчитать, как именно поведёт себя база при росте числа пользователей и объема операций.

Первичный анализ системы

Первый шаг в построении математической модели нагрузки — сбор данных о текущей системе:

• данные технологического лога ( для 1С — тех. журнал);
• данные о поведении пользователей (регламент работы)
• данные о действиях пользователя (для 1С — журнал регистраций);
• первичная информации из базы данных (количество, документов, вес документов, частота операций).

Конечно, полная картина не всегда доступна: иногда невозможно получить технологический журнал 1С, SAP или другой системы. Но даже в этом случае остаются источники, из которых можно извлечь полезные данные: логи пользовательских действий, статистика базы данных, метрики мониторинга. Этого уже достаточно, чтобы понять, как пользователи взаимодействуют с системой и какие сценарии создают основную нагрузку.

Следующий шаг — на основе этих данных определить, какие именно документы и операции нужно генерировать, чтобы воспроизвести нагрузку в тестовой среде. При этом важно не просто «нажимать кнопки» в интерфейсе: создать документ, провести его, сформировать отчёт — всё это нужно промоделировать на реалистичной базе данных, заполненной хотя бы за один год работы.

В противном случае вы не увидите, скажем, неоптимальные алгоритмы, которые могут быть заложены в коде. Например, вместо того чтобы выбрать данные по индексу, алгоритм может каждый раз читать всю таблицу целиком – на маленькой базе такую проблему не увидеть.

Типичные ошибки и проблемы при неверной интерпретации данных

Равномерное распределение и пропуск дополнительных блокировок СУБД

Одна из распространенных ошибок — усреднение данных. На первых проектах многие инженеры, как и я когда-то, брали статистику в целом по предприятию: например, «в среднем создаётся 10 000 документов в день, значит, примерно тысяча в час – давайте возьмем 3000 в пиковый час и распределим».

Казалось бы, логично. Но на практике нагрузка почти никогда не бывает равномерной.

Моделирование только одного сценария, когда возможно несколько

Кажется логичным: возьмем самый «тяжелый» час, когда пользователи создают больше всего документов, и посмотрим, выдержит ли система. Но на деле это лишь часть картины.

Нагрузка на систему почти никогда не статична — она меняется в течение суток. Днём, например, активнее идут денежные операции, формируются отчёты, оформляются документы. А ночью может работать производство или логистика.

В одном из проектов у клиента основная продукция — колбасы, куры, яйца — оформлялась и отгружалась днём. Но был один особый процесс: отгрузка сала, и она шла исключительно ночью. Этот сценарий создавал совершенно другой профиль нагрузки и открывал новые узкие места, которые не были видны в дневных тестах.

Неучтенная повторяемость и ряды данных на операции

При вычислении средних значений этот фактор часто не учитывается, хотя именно он может существенно влиять на поведение системы.

В реальных сценариях одни и те же операции — например, создание заказов, обновление остатков или проведение отчётов — повторяются с определённой периодичностью. Между ними есть временной интервал: пять минут, час, день. И эти интервалы создают собственный ритм нагрузки.

Если в модели просто усреднить данные, эта цикличность исчезнет. Система будет выглядеть стабильной, но это иллюзия.
Чтобы добиться реалистичного результата, нужно моделировать повторяемость:

• учитывать, на каком временном промежутке повторяются операции;
• задавать взаимосвязи между данными, которые выполняются не одновременно, а с отставанием во времени;
• выстраивать тестовые сценарии так, чтобы отражать естественные колебания активности пользователей.

Именно такая детализация позволяет модели воспроизводить реальные пики и спады, а не усреднённую и «стерильную» картину нагрузки.

Неинтерактивные операции: скрытая нагрузка системы

Ещё один источник искажений — неинтерактивные операции, то есть те, которые выполняются не пользователем, а системой автоматически.

Это могут быть, например, расчёт остатков, формирование заказов клиентов, обновление данных по алгоритму или с участием искусственного интеллекта.

Такие операции не распределяются равномерно по времени и мощности. Они запускаются через определённые промежутки — по расписанию, по событию или при достижении условия в данных. В результате нагрузка может резко возрастать в неожиданные моменты, даже когда пользователи не активны.

Поэтому неинтерактивные процессы нужно анализировать отдельно:

• определить, как часто и при каких условиях они запускаются;
• рассчитать, какую долю общей нагрузки они создают;
• при необходимости — смягчить пики, распределив выполнение заданий во времени.

Такой анализ помогает избежать ситуации, когда ночью или в «тихий час» система внезапно начинает испытывать перегрузки  из-за автоматических процедур, о которых забыли при планировании нагрузки.

Конфликты блокировок и длительные ожидания

Когда создаётся модель с усредненными параметрами — допустим, 1800 виртуальных пользователей, равномерно выполняющих операции, — кажется, что система работает стабильно. Графики ровные, процессор не перегружен, база отвечает без задержек.

Но в реальной эксплуатации пользователи действуют неравномерно: кто-то нажимает кнопку «провести документ» в ту же секунду, что и десятки других, кто-то запускает отчёт, кто-то массово выгружает данные.

Если нагрузку распределить слишком ровно, тест просто не поймает эти конфликты. А значит, в продакшене они проявятся неожиданно — под реальной нагрузкой, когда исправить проблему будет гораздо дороже.

Отсутствие административных решений для снижения нагрузки

Еще одна ошибка — игнорирование управляемых пиков. Иногда пиковые операции можно разгрузить организационно: например, зачем запускать расчёт себестоимости или анализ потребления клиентов в 3 часа дня, когда система и так перегружена? Простое административное решение — перенести эту задачу на ночь — может снизить нагрузку без изменения кода и архитектуры.

Неверная оценка пиковых нагрузок

Часто инженеры анализируют лишь крупные операции, упуская из виду мелкие, но массовые действия, которые в пиковый час тоже создают дополнительную нагрузку. Тот самый пример с фронтальными погрузками: операция вроде бы второстепенная, но именно она «добавляет изюминку» в общий пик и создаёт узкое место.

Важно рассматривать все типы операций в пиковых часах, а не только самые большие по объёму данных.

Несогласованность результатов тестов и математической модели

И наконец, ключевая ошибка — отсутствие верификации модели. Результаты нагрузочного тестирования должны быть подтверждены математическим моделированием.

После проведения теста нужно снова собрать статистику — уже по итогам моделирования — и сравнить её с исходными данными, на основе которых строилась модель.
Если всё сделано корректно, результаты должны совпадать в обе стороны:

• математическая модель предсказывает то, что показал тест;
• тест подтверждает то, что было рассчитано моделью.

Эта обратная связь — ключ к достоверности.

Математический аппарат для моделирования

Когда мы приступаем к математическому моделированию нагрузки, важно принять одну простую установку: мы не знаем систему досконально. Да, в реальности данные не случайны — клиенты совершают осознанные действия, заказывают определённые товары или услуги. Но для того, чтобы построить модель, мы временно предполагаем случайность данных. Это позволяет выявить скрытые зависимости и закономерности, которые неочевидны при обычном анализе.

Например, мы замечаем, что заказчик X чаще всего покупает продукт A, и делает это каждую среду в 15:00. На первый взгляд — случайность, но при математическом анализе таких паттернов становится видно, что именно этот временной промежуток создаёт пиковую нагрузку.

Постепенно, рассматривая подобные повторяющиеся сценарии во всех рядах данных, мы можем определить, в какой час и для каких операций возникает наибольшее отставание или перегрузка. В результате модель начинает отражать реальные закономерности системы: мы уже не просто генерируем случайные действия пользователей, а воспроизводим их поведение с учётом повторяемости и цикличности.

Вариация данных

Учитываем следующие моменты:

• абсолютные отклонения;
•  коэффициент вариации случайной величины;
• дисперсия.

При анализе дисперсии мы смотрим, какие элементы системы повторяются чаще всего:

• какая номенклатура пользуется наибольшим спросом;
• какие контрагенты чаще совершают операции;
• по каким договорам или проектам идут основные транзакции.

Затем анализируем временные параметры: в какой час, в какой день недели происходят пики активности, есть ли сезонность или повторяющиеся паттерны.

Когда эти закономерности выявлены, важно правильно подготовить тестовые данные.

Нельзя ограничиться одним шаблоном документа, который просто копируется и записывается: в реальной жизни система работает с множеством похожих, но не идентичных операций: разные клиенты, разные товары, разные параметры заказа.

Поэтому для корректного моделирования нужно создать разнообразные шаблоны, например:

• 10 шаблонов документов для одного контрагента;
• 10 — для другого;
• и так далее.

Эти документы должны создаваться и проводиться с разным временным распределением — часть сразу, часть спустя час или два. Так модель начинает отражать естественное поведение системы: повторяющиеся, но не одинаковые операции, которые и создают настоящую нагрузку в боевых условиях.

Корреляция данных

Как уже говорилось, при построении модели мы часто не знаем изучаемую систему досконально. Мы не можем точно сказать, почему тот или иной контрагент заказывает определённые товары или почему отгрузка идёт с конкретного склада. Но это не мешает нам измерить связи между событиями — понять, какие из них повторяются вместе и насколько тесно они связаны.

Для этого применяется корреляционный анализ — один из базовых инструментов математического моделирования нагрузки.

Мы собираем статистику и сводим её в таблицу:

• какие контрагенты чаще повторяются в заказах;
•  какие товары и номенклатуры продаются вместе;
• с каких складов и куда чаще всего происходят отгрузки.

Далее с помощью корреляционного анализа измеряется теснота связей между параметрами. Это позволяет понять, какие элементы системы взаимозависимы, а какие действуют независимо. Корреляционный анализ позволяет смоделировать нагрузку, максимально приближенную к поведению реальных пользователей: где пики совпадают, где операции взаимно усиливают друг друга, и какие комбинации действий создают ключевые точки перегрузки.

Ниже — графики из реальных проектов, в моменты, когда проходила реализация товаров и услуг. У нас есть 55 минут, разделенные на интервалы по 5 минут.

Вот пример расчетов во времени, где мы взяли и распределили средний документ во времени, без математического моделирования. Соответствует ли это реальности? Конечно, нет.

В реальности загрузка шла так: документы в основном проводились с 20 по 35 минуту.

Еще один пример: в этой ситуации документы проводились только в начале и в конце часа — по такому графику подъезжали фуры с товаром.

А здесь отгрузка продукции проходила в зависимости от того, как цех ее выдавал.

Ни один из этих реальных сценариев не был даже приближен к усредненному.

Проверка на парадокс Симпсона

При работе со статистикой важно помнить: средние значения могут вводить в заблуждение. Это особенно заметно, когда данные разбиваются на несколько групп — например, по складам и по контрагентам.

Предположим, мы анализируем, как часто определённая номенклатура продаётся с конкретных складов и определённым клиентам. Если рассматривать эти параметры по отдельности, может показаться, что между ними существует очевидная зависимость.

Но стоит объединить данные — рассмотреть продажи одновременно по складу и по контрагенту, — и картина резко меняется: связи ослабевают или вовсе исчезают.

Это не ошибка и не признак «плохих» данных. Парадокс Симпсона — сигнал к более глубокому анализу.

Если при объединении групп результат сильно меняется, значит, в системе есть скрытые факторы, влияющие на поведение пользователей или структуру данных.

В контексте нагрузочного тестирования это особенно важно: игнорируя такие различия, можно построить модель, которая кажется статистически корректной, но не отражает реальную структуру взаимодействий в системе.

Когда математическая модель готова и мы запускаем нагрузочное тестирование, важно правильно интерпретировать результаты распределения операций во времени.

На примере выше показаны реальные данные — сценарий работы банка. В ходе тестирования роботы имитировали действия пользователей, и стало видно, как распределяется активность по минутам.

Банковские выписки начинали обрабатываться примерно на 30-й минуте часа и завершались к 50-й. Таким образом, активная фаза длилась всего около 25 минут, в течение которых система испытывала реальный пик нагрузки.

Если бы мы распределили операции по среднему, график выглядел бы плавным и аккуратным — без выраженных всплесков. Но в жизни всё иначе: реальные пользователи создают неровные, импульсные нагрузки, и именно их нужно моделировать.

Верхняя часть таблицы отражает интерактивные действия, которые выполняют пользователи вручную (в тесте их заменяли роботы). Эти операции имеют относительно ровное распределение — по 5 минут, без выраженных скачков.

Ниже видны регламентные задания — автоматические процессы, которые запускаются системой по расписанию или в ответ на событие. Именно они формируют наиболее сложные пики нагрузки.

На графике видно: в один момент времени система обрабатывает всего 23 документа, а в другой — полторы тысячи.

Смоделировав ситуацию, мы получили такую таблицу операций и график загрузки. На графике видно, что загрузка процессора распределена неравномерно: вместо плавного роста и спада мы видим отчётливые пики. Самые нагруженные интервалы — с 10-й по 20-ю минуту и с 20-й по 30-ю. Именно в эти промежутки система испытывает наибольшее давление.

Интересно, что в среднем процессор выглядит вполне «здоровым» — загрузка колеблется в районе 80%, запас по вычислительной мощности остаётся.
Но если присмотреться к пикам, видно, что они достаточно длительные и повторяются с определённой периодичностью.

Если анализировать ситуацию только по среднему значению (жёлтая линия на графике), можно сделать ложный вывод: «Всё отлично, давайте снимем часть серверов — у нас есть запас».

На практике это приведёт к тому, что в пиковые минуты система начнёт «задыхаться» — появятся тайм-ауты, блокировки, замедления и сбои в обработке операций.

Неслучайная случайность: как проверить корректность модели

После того как основные тесты проведены и результаты зафиксированы, инженеры переходят к исследовательской фазе — проверке устойчивости модели. Для этого выполняется серия дополнительных тестов с другими, случайно сгенерированными наборами данных.

Цель этих тестов — убедиться, что поведение системы не зависит от конкретных входных данных, а отражает закономерности, заложенные в алгоритмах.

Анализ разброса

Результаты сравниваются с показателями основного теста. Если графики сильно расходятся, это сигнал, что алгоритмы зависят от структуры данных.

В таком случае нужно искать причину:

• либо в бизнес-логике — например, модель бизнес-процессов построена некорректно;
• либо в коде — часто встречаются неоптимальные запросы, избыточные условия, из если/иначе, замедляющий обработку.

Как показывает практика, чаще всего проблема именно во втором — «gkj[jq код».

Модель условной вероятности

Эта часть анализа называется «неслучайная случайность». Мы предполагаем, что все данные случайны, но на самом деле они подчиняются условным вероятностям.

Инженеры строят математическую модель, описывающую вероятности появления определённых событий — например, что контрагент X покупает товар A с вероятностью 0,7, а товар B — с 0,3.

Если при нагрузочном тестировании полученные результаты подтверждают эти вероятности, значит, математическая модель построена корректно.

Если нет — модель нужно пересматривать: либо данные сгенерированы неправильно, либо алгоритмы обработки искажены.

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

В таком случае необходимо составить таблицу зависимости значений и проанализировать их. Например, значения номенклатуры или склада.

Таким образом, «неслучайная случайность» — это финальный этап валидации: проверка того, насколько точно математическая модель отражает реальную систему.