О нагрузочном тестировании BI-платформы
Нагрузочное тестирование BI-платформы – это процесс измерения производительности и стабильности платформы бизнес-аналитики при высоких нагрузках, который позволяет оценить способность BI-системы обрабатывать большие объемы данных, быстро предоставлять аналитические отчеты и реагировать на запросы пользователей в условиях пиковых нагрузок.
Проведение нагрузочного тестирования BI-платформ позволяет выявить потенциальные проблемы производительности, улучшить стабильность и надежность системы, а также гарантировать, что платформа будет эффективно справляться с высокими нагрузками в рабочей среде.
При работе с крупными проектами часто возникают следующие вопросы:
Как подобрать конфигурацию серверов?
Выдержит ли система требуемую нагрузку?
Сколько конкурентных пользователей выдержит система?
Какой максимальный объём данных можно загрузить?
Как оценить масштабируемость системы?
Как оценить стабильность системы при продолжительной нагрузке?
Как понять, что при обновлении система продолжит корректно работать?
Будет ли система выдерживать пики нагрузки?
На все эти вопросы поможет ответить нагрузочное тестирование, но при этом следует учитывать особенности BI-проектов, а именно:
Чем больше self-service кейсов, тем сложнее предсказать нагрузку.
Существует большое количество факторов, влияющих на производительность:
Количество строк и объём данных в ГБ;
Количество пользователей;
Кардинальность данных;
Сложность модели и связей;
Сложность аналитических запросов;
Сложность дашбордов;
Количество уникальных запросов / фильтраций;
Сложность и частота загрузки данных;
Качество оптимизации внешних хранилищ для случая ROLAP;
Количество уникальных ролей доступа;
и т.д.
Таким образом, нагрузочное тестирование BI-платформы – это сложный процесс, который может занять от пары недель до нескольких месяцев.
Этапы тестирования производительности
1. Формирование команды
Для произведения нагрузочного тестирования требуются следующие специалисты:
Специалист в области тестирования производительности;
Аналитик;
Специалист, разбирающийся в конкретной BI-платформе (например, представитель вендора).
2. Анализ требований
Целевая аудитория:
"read-only" пользователи;
аналитик self-service;
администратор;
пользователи форм ввода (Smart Forms).
Метрики
Response time — время отклика (макс, мин, среднее, процентиль, медиана и т.д.);
CPU / RAM / DISK / NETWORK.
Профиль нагрузки (набор операций с заданными интенсивностями, полученный на основе сбора статистических данных, либо определенный путем анализа требований к тестируемой системе)
запрос;
транзакция;
сценарии.
Выбор вида тестирования
нагрузочное тестирование (рост и далее работа какого-то количества пользователей на отрезке времени);
тестирование на выносливость (подача одной и той же нагрузки на продолжительное время);
стресс-тестирование (доведение системы до предела возможностей и определение границы возможностей);
spike-тестирование (нагрузки в пике);
тестирование масштабируемости;
объёмное тестирование.
3. Подготовка стенда и выбор инструмента тестирования
Ниже приведен пример конфигурации стенда:
В данном примере, в жёлтом блоке (платформа Visiology), показано несколько серверов, отвечающих за слой application, а также несколько серверов, отвечающих за In-memory БД. Есть какое-то хранилище, с которым взаимодействует платформа и, допустим, присутствуют серверы ETL, которые занимаются процессом преобразования данных. Серверы JMeter используются для генерации нагрузки (важно, чтобы они были отдельно, чтобы не было т.н. “Навода помехи” на основой контур (Visiology).
Популярные инструменты для проведения нагрузочного тестирования
Ниже приведен список инструментов, с помощью которых вы можете провести нагрузочное тестирование:
Apache JMeter;
Яндекс.Танк;
Puppeteer;
Gatling;
HP LoadRunner.
Концепция тестирования
При нагрузочном тестировании платформы требуется тестирование только клиент-серверной части, исключая браузер. Практика показывает, что тестирование браузера делает задачу трудоёмкой и не вполне целесообразной. Дашборды проще “покликать” вручную и таким образом проверить их работу. Поэтому заострим внимание именно на тестировании клиент-серверной части с помощью JMeter. Этот инструмент не использует браузер и работает на уровне HTTP, эмулируя запросы реальных пользователей в сети. JMeter обладает следующими преимущетвами:
развитый UI с возможностью отладки записи;
много инструментов для анализа метрик и построения графиков;
открытый исходный код;
большое количество плагинов;
запуск в кластере;
большое комьюнити;
специалисты в РФ.
Тем не менее, стоит отметить, что для больших нагрузок JMeter необходимо настраивать. Он не очень производителен “из коробки”, особенно что касается потребления памяти.
Запуск и анализ результатов
Итак, JMeter запущен и показывает какие-то результаты. По метрикам, которые были приняты на этапе анализа требований, производится сверка (по каким метрикам проходит, какое количество ошибок, загрузка CPU и прочее). Если по каким-то метрикам результат неприемлем, то вам необходимо либо вернуться на предыдущий этап (например, могли быть неправильно заданы требования, неправильно подготовлен стенд и т.д.), либо перейти к настройке системы, конфигурации, сети, хранилища, дашбордов и т.д. для повышения соответствия необходимым метрикам.
Типовые ошибки при тестировании
При проведении нагрузочного тестирования могут совершаться типичные ошибки:
Тестируется только часть компонентов.
Например, тестируются только запросы в БД и не тестируется следующее:запросы в BI-платформу;
запросы мета-данных;
запросы на статику;
запросы на авторизацию;
и т.д.
Не учитывается процесс загрузки данных.
Попытка протестировать все возможные сценарии во всех конфигурациях.
Обычно это выливается в то, что проект становится “неподъёмным”. Тестирование производительности очень трудоёмко. Из всех сценариев и конфигураций нужно выделить только то, что точно влияет на производительность.Тестирование не воспроизводимо.
Например, прив первом запуске время отклика составило <2 сек, при втором тестировании – <20 сек, при третьем – <10 сек. Это может говорить о наличии какой-то помехи для теста (например, какой-то неучтённый процесс на сервере, или JMeter запустили на том же сервере, на котором развёрнута платформа, и таким образом какой-то процесс, не связанный с платформой, начинает сильно влиять на время отклика самой платформы. Тестирование должно быть воспроизводимо, т.е при нескольких запусках должны быть примерно одни и те же результаты в пределах погрешности.Не используются случайные величины.
Могут использоваться одни и те же фильтры и данные. В итоге все запросы попадают в кэш и метрики могут отличаться от реальных показателей на порядок.Используются автоматически сгенерированные данные.
Реальные данные часто сильно отличаются от сгенерированных, так как сгенерированные данные, как правило, более оптимизированы.Слишком малое время тестирования.
Условные полчаса — это очень мало. Реальные кейсы могут предполагать запуск продолжительностью до нескольких дней.Не учитывается аутентификация.
Её стоит учитывать, если применяются разные права доступа у пользователей. К примеру 10000 пользователей с разными правами будут генерировать разную нагрузку, что необходимо учитывать.Не учитываются права данных — RLS и OLS.
Запуск в рабочее время, когда на стенде работают реальные пользователи.
Выводы
Итак, подведём итог. Для проведения качественного нагрузочного тестирования необходимо сделать следующее:
максимально подготовить окружение под высокую производительность, особенно это касается производительности сети и работы операционной системы с сетью;
настроить инструменты тестирования;
подготовить реальные данные;
придумать реальные сценарии;
не использовать и не нагружать компоненты, которые не будут использоваться в повседневной работе;
определиться с требованиями об успешности тестирования при различных видах нагрузки;
повторять тестирование.
Смотрите также
На этой странице
| Оглавление |
|---|
🕑 Время чтения: 2 мин.
Нужна дополнительная помощь?