Высокая производительность платформы автоматизации – ключевой параметр при ее выборе для средних и крупных компаний. Инсталляция подобных систем — процесс дорогостоящий. Произвести полную установку, переезд на систему, а потом упереться в то, что новая система не выдерживает количества пользователей – это потеря огромного количества денег.
Но как заранее оценить, что платформа справится с конкретным объёмом операций? Провести нагрузочное тестирование. В этой статье мы поделимся опытом, как проводим оценку производительности для заказчиков SimpleOne.
Тестирование вместо обещаний
Разработчики платформы, безусловно, понимают, под какой объём пользователей заточено их решение. Поэтому заказчик и без тестирования получает от производителя информацию, на какие нагрузки ему рассчитывать. Но в такой оценке нагрузочного потенциала платформы «навскидку» есть своя проблематика.
Представим две компании-разработчика: №1 и №2. Компания №1 заявляет в своих маркетинговых материалах, что их платформа выдерживает 1 миллион операций за определённый промежуток времени, а №2 за тот же – всего 500 тысяч. Казалось бы, первая платформа производительнее в два раза, её преимущество очевидно. Однако названые цифры на самом деле могут означать совсем разные типы производительности.
Дело в том, что, когда пользователь производит действие, например, нажимает «сохранить запись» у каждой системы происходит в этот момент определённое количество проверок, обращений, непосредственно выполнений сохранений сопроводительных данных. То есть одно действие пользователя вызывает большое количество операций, которые приводят к одному конкретному результату – выполнению запрошенного от платформы действия. И у одной платформы на это действие может уходить 200 операций, а у другой – 2000. И получится, что действие и там, и там одно, но силы, которые система затрачивает на его реализацию, отличаются в 10 раз. Соответственно может оказаться, что платформа №1 производит очень много операций, но не так много фактических действий, а платформа №2 тем временем тратит меньше операций на одно действие, успевая выполнить больше.
Таким образом, количество операций, которые производит платформа за единицу времени – не показатель производительности системы.
Можно сделать и больше бесполезных, зато легких и быстрых операций, тогда и 2 миллиона будет. Только производительность, которая нужна клиенту, чтобы действия его пользователей быстро обрабатывались, расти не будет.
SimpleOne для иллюстрации производительности приводит количество действий пользователя. Это универсально для всех систем: везде нужно нажать кнопку «Сохранить», открыть список, открыть конкретную запись и т.д. Это гораздо более наглядно.
При этом разные действия требуют разного количества операций. Одна платформа тратит меньше операций на действия, связанные с созданием документов, другая быстрее справляется с их распространением. В оптимальном сочетании ёмкости действий и прячется производительность. Поэтому SimpleOne всегда готова к тестированию платформы, чтобы показать, что нагрузки, которые могут присутствовать у заказчика, платформа выдержит.
Нагрузочное тестирование: наш опыт
Нагрузочное тестирование показывает при каком максимальном количестве разнообразных запросов и действий платформа будет работать корректно. Для такого исследования мы в SimpleOne используем JMeter. Этот инструмент давно известен, у него широкая и надёжная функциональность, разработала его компания Apache ¬– крупнейший веб-сервер в мире. Программа направляет такие же запросы, как делал бы браузер при работе настоящего пользователя в SimpleOne. И такие же запросы, как делали бы сторонние системы к платформе через Rest API. Позволяет проверить работу как с консоли, так и с пользовательского интерфейса.
При исследовании нагрузки системы важно определиться непосредственно с профилями тестирования, то есть какие именно запросы и в каких количествах делать, чтобы тест был достоверным.
У продукта SimpleOne есть несколько источников нагрузки:
- агентский интерфейс (для агентов);
- портальный интерфейс (для рядовых сотрудников);
- нагрузка от сторонних пользователей через API.
С учётом этих трёх источников нагрузки, для тестирования пишутся скрипты, которые эмулируют запросы пользователей к платформе: авторизация, создание записей, просмотр форм, листов, нажатия на кнопки, настройка фильтров и прочие переходы по страницам. Мы формируем такой набор для разных типов клиентов-пользователей:
- Агенты service-desk, которые работают в агентском интерфейсе;
- Пользователи, которые приходят на портальный интерфейс за внутренним сервисом;
- Администраторы, которые могут вносить изменения в саму систему.*
*Категорию «Администраторы» мы включаем в тестирование довольно редко, так как их количество в числе пользователей несопоставимо мало. При этом нагрузку они выдают не больше агентов и часто работают не на продакшн серверах, а на дев сервере, чтобы сначала подготовить, проверить и только потом внести изменения.
Ролей может быть несколько больше, в том числе нечеловеческих. Например, наша система умеет общаться по REST API и, если предполагается что какие-то сторонние системы будут к ней обращаться по этому протоколу, мы предусматриваем и такую нагрузку.
Самое важное в подготовке тестирования – тест-план: настройка количества и процентных соотношений различных запросов за определённый промежуток времени. По этому количеству и будет проверяться прочность системы.
На этапе подготовки тест-плана тестирование идёт по двум путям в зависимости от того, есть ли у нас исходные данные для таких настроек или нет.
Тестирование по готовым данным
Компании-заказчики, для которых и проводится 90% тестирований, зачастую переходят на нашу систему с других корпоративных систем учета данных. Если старая система заказчика позволяла производить такие действия как: просмотр списков, записей, редактирование и т.д, это облегчает подготовку тест-плана. Можно обратиться к логам веб-сервера старой системы, и по ним понять все количества и процентные соотношения действий, которые производились пользователями. Далее взять период за неделю, найти пиковый час, умножить его на 2 и преобразовать его в конкретные действия – тест-план готов.
Тестирование без принципиальных данных
Второй случай – когда логов от заказчика нет. Тогда на помощь приходит статистика аналогичных систем с теми ролями пользователей, которые нужны заказчику. Берется каждая из ролей, и в ней делаются допущения на основе запросов заказчика и целей тестирования.
Например, мы знаем, что агент будет работать в постоянном режиме с системой, его норматив – обработать в течение дня минимум 20 инцидентов. Мы делаем вывод, что такой пользователь постоянно будет открывать списки инцидентов, конкретные инциденты, комментировать записи в беседах с авторами инцидентов, переводить запись из одного статуса в другой, сохранять и т.п. Представив усредненный рабочий день агента, мы получаем картину по тому, сколько каких запросов к системе он будет делать, и умножаем это на количество агентов.
Для нагрузки от пользовательского интерфейса прорабатываются уже другие запросы. Например, они заходят реже, когда что-то ломается, нужно сообщить о чём-то или на что-то отреагировать. Значит, основные действия: зарегистрировать инцидент, обращение, дать обратную связь по инциденту. Далее учитываем, что пользователь даёт гораздо меньшую нагрузку, но при этом этих единиц (простых пользователей) в десятки раз больше, чем агентов, поэтому общий объем оказывается тоже значительным.
Таким образом мы формируем конкретные действия пользователей и дальше переводим их в конкретные обращения в Jmeter.
Пример тестирования
Одно из тестирований мы проводили с задачей в минимум 66 тысяч действий агентов service-desk в час. Такую нагрузку мы запускали на отдельно сделанный инстанс SimpleOne.* На нём создавали все наши приложения, платформу и прочее.
*Помимо наших инстансов, на более поздних этапах предпроектного исследования мы прогоняем тестирования в инфрастурктурах и инстансах заказчиков.
Основная часть тестирования проводилась на 48 ядрах процессора по 2 ГГц, дополнительно были проверены показатели по 4 и 64 ядрам. При тестировании всегда был включён механизм SLA, чтобы оценить дополнительную нагрузку, которую он даёт процессу создания записей. Дополнительно мы создавали большое количество данных (около 20 млн инцидентов), поскольку тестирование проводилось для компаний с большим количеством записей. Так мы хотели понять, как система ведет себя на основе таких больших данных: насколько быстро работают фильтры, насколько отрабатываются бизнес-правила, SLA, индикации и т.п.
Платформа показала отличную производительность с количеством запросов в полтора раза больше установленных (рис. 1 и 2). Так, мы с уверенностью смогли заключить, что способны выдерживать объём операций крупных компаний.
Приведённое в пример тестирование проводилось в марте 2021 года. Работа над платформой ведётся непрерывно, и данные показатели в настоящее время ещё выше. На это повлияло и недавнее обновление платформы SimpleOne до версии 1.8.
Тест как основа для роста и принятия решения
Нагрузочное тестирование – важный этап предпроектного обследования. Оно помогает разработчикам быстро находить узкие места в производительности системы и исправлять их, а заказчикам помогает понять и увидеть на практике, отвечает ли платформа их задачам и каков её запас прочности. Мы всегда советуем нашим заказчикам проводить тестирование системы, не жалеть на него ресурсов. Ведь уверенность клиента в правильности выбора платформы – немаловажная составляющая успешности всего проекта автоматизации.
