Один из главных аргументов против цифровых сервисов — возможные технические ошибки, которые возникают в самый неподходящий момент. Например, когда инспектор ждет документацию на проверку, а нужный раздел системы не загружается. Почему могут возникать перебои в работе сервисов и как заказчику заранее проверить надежность цифровой платформы, разберемся в статье.
Определить требования к системе
Каждый пользователь на своем опыте встречался с техническими неполадками в системе. Пример из жизни: пассажиру нужно срочно купить билет, а сервис онлайн-касс загружается несколько минут. Дождавшись, пользователь внимательно заполняет свои данные, переходит к следующему шагу и видит, что данные не сохранились. Так бывает, когда слишком много людей одновременно с ним попытались купить билеты, и сервис не смог обработать все запросы.
Причинами технических сбоев могут быть неоптимизированные запросы, неправильно спроектированная архитектура приложения, неправильно организованная инфраструктура: недостаточная мощность или количество серверов, маленький размер дискового пространства, низкая скорость чтения и записи данных у средств хранения информации, низкая пропускная способность между серверами. Иногда сбои могут быть связаны с аппаратным комплексом, а в некоторых случаях — с неправильными настройками оборудования. Если говорить проще, любая система одновременно может выполнить ограниченное количество действий. Какое конкретно количество, выясняют при нагрузочном тестировании системы.
Нагрузочное тестирование систем — это испытания, при которых искусственно создают условия, приближенные к реальному использованию. Испытания помогают определить, сколько пользователей одновременно способна выдержать система. Допустим, нужно чтобы при одновременной работе тысячи пользователей система отвечала на запрос не дольше 60 секунд. Тогда во время теста создают нагрузку, имитирующую работу тысячи пользователей, и фиксируют показатели.
Результаты нагрузочного тестирования нужны разработчикам системы, чтобы вовремя подключить дополнительные мощности и не допустить ситуаций, когда сервис перестанет работать.
Выбрать виды и методики тестирования
Существуют разные виды тестов. Выбор зависит от того, что конкретно нужно проверить.
- Непосредственно нагрузочное тестирование покажет, справляется ли приложение со средней нагрузкой на него.
- Тесты на стабильность проверяют работоспособность продукта на длительном промежутке времени.
- Тесты на отказоустойчивость помогут определить, как быстро система возобновит свою работу на новом сервере или в облаке, если основной сервер откажет.
- Тесты на восстановление — подвид теста на отказоустойчивость, который покажет, сколько времени системе требуется, чтобы развернуться заново.
- Стресс-тесты помогут определить работоспособность продукта при пиковых нагрузках.
- Тесты объема проверят работоспособность системы при резком увеличении количества пользователей.
- Тесты масштабируемости покажут, насколько быстро разворачиваются новые кластеры в облаке.
- Тесты потенциальных возможностей — тест, который определит предельные возможности приложения: максимальное количество пользователей в минуту, предельное число записей в базе данных, количество одновременно открытых коннектов и прочее.
Во время нагрузочного тестирования системы фиксируют следующие показатели:
- Среднее время отклика — периоды между созданием запроса и получением результата усредняются, чтобы получить среднее время ответа.
- Пиковое время отклика — максимальное время, за которое сервер создал ответ на запрос пользователя.
- Частоту ошибок — соотношение между успешными и безуспешными запросами.
- Количество одновременных пользователей.
- Производительность — количество запросов, выполненных за единицу времени.
Провести испытания
Как проходит тестирование производительности программы, рассмотрим на примере испытаний информационно-аналитической системы «Цифровое управление строительством». На этапе подготовки нужно решить ряд вопросов. Во-первых, определить, какие операции чаще всего совершают пользователи в приложении: именно их и нужно проверять. Затем на основе этого составить сценарии, в которых описано, что будут делать виртуальные пользователи во время теста. И наконец, определить количественные показатели: сколько времени проводить тест, какое количество пользователей должно быть создано в процессе испытаний, за какой промежуток времени и какие результаты считать успешными.
Для испытаний платформы ЦУС подготовили тестовый стенд и написали скрипты. Один сервер создавал нагрузку — виртуальных пользователей, которые отправляли запросы. Сервис-балансировщик распределял эту нагрузку между двумя серверами приложений. А серверы приложений передавали запросы на сервер баз данных и отдавали ответ.
Тестирование производительности программы проводили в два этапа. На первом этапе проверили работу основных, часто используемых модулей приложения. На втором этапе тестировали формирование больших аналитических отчетов, виджетов — это более ресурсоемкая задача, которая связана с обработкой большого количества данных из множества таблиц.
Оценить результаты тестирования
Какие результаты можно считать успешными — зависит в первую очередь от особенностей приложения и инфраструктуры. В случае с системой ЦУС установили такие требования: при тестировании система должна выдержать нагрузку не менее тысячи одновременных пользователей, при этом время ответа не должно превышать 60 секунд. Количество пользователей увеличивалось на 500 каждые 20 минут. В результате за время теста создали 10 тысяч пользователей, каждый из которых выполнял конечный сценарий.
При проведении стресс-теста система должна была выдержать нагрузку в две тысячи одновременных пользователей, а время ответа также — не превышать 60 секунд. Количество пользователей увеличивалось на 500 каждые 5 минут. За время теста также создали 10 тысяч пользователей, каждый из которых выполнял конечный сценарий.
Во время тестирования производительности программы максимальное количество одновременных пользователей ЦУС достигло 1795, среднее — около 1200. Время ответа не превышало 60 секунд и в среднем составляло 7 секунд. Критические ошибки и аппаратные сбои не возникали. Тестирование проводилось непрерывно 8 часов.
По результатам стресс-теста первый сбой был зафиксирован при 2310 одновременно работающих пользователях. При 3102 одновременных пользователях количество ошибок не превышало 5% от общего числа операций. Ошибкой в данном случае считается время ответа, не соответствующее установленным требованиям. При 5902 одновременных пользователях время ответа ЦУС достигло установленного ограничения в 60 секунд. Критических ошибок и аппаратных сбоев не было. Тестирование проводилось непрерывно 1 час 40 минут.
Как мы уже говорили, производительность системы во многом зависит от архитектуры приложения. В ЦУС для каждого заказчика создается отдельная база данных. Разработчики регулярно отслеживают количество и активность клиентов и, если нужно, подключают дополнительные серверы приложений и баз данных. То есть систему масштабируют, не дожидаясь, когда нагрузка станет критической и начнутся сбои.
Нагрузочное тестирование аналитических инструментов системы проводили отдельно потому, что сбор данных для аналитики, как правило, представляет собой выборку из множество связанных таблиц с применением фильтрации данных. Причем у разных пользователей с разными ролевыми моделями и правами доступа набор обрабатываемых данных будет разный.
Тестирование производительности программы в части аналитикии показало, что при одновременной работе тысячи пользователей время формирования отчета, данные для которого собирали из разных модулей, не превышало 60 секунд.
Резюме
Нагрузочное тестирование цифровой системы помогает определить, при каком количестве одновременных пользователей она работает стабильно, без ошибок. Испытания информационно-аналитической системы ЦУС показали, что не менее 3100 пользователей могут одновременно работать в ней. Система контролирует рост нагрузки и распределяет ее. Если количество пользователей начнет стремиться к 3100, инфраструктура будет масштабироваться. Своевременный контроль и тестирование позволяют сохранять стабильность и скорость работы системы на оптимальном уровне.
