Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Web-система. Ver 1.0
К нам обратился клиент, который хотел выполнить тестирование своей системы на возможность выдержать работу 42 000 пользователей. Они представили нам свой продукт и требования работы данного продукта:
Опросник международного уровня;
Содержал около 5 вкладок для перехода и переключение языка;
Срок работы опросника всего неделю, но судя по требованиям он должен был быть максимально стабильным и работать безотказно;
Ручное время выполнения сценария пользователем должно было составлять примерно 50 - 60 секунд по заявлениям заказчика.
По результатам такого описания было понятно, что ресурсов на его развертывание они могут выделять достаточно много.
И так, что же было у них под “капотом”:
Каждый переход по вкладке динамически загружал данные по технологии WebSocket;
На странице использовался JS, CSS;
Около 50 - 60 картинок;
Файл языкового пакета.
В то время WebSocket только начала широко использоваться и его стремились использовать все кому не лень. Ведь это была новая технология, которая должна была обеспечивать быструю передачу данных за счет постоянно открытого соединения.
У нас новомодная технология и наша система высокопроизводительная... ?!
И так получив систему, мы были ознакомлены и с предоставляемым профилем нагрузки (клиент хочет, клиент платит - кто мы такие, чтобы спорить). Профиль нагрузки был амбициозный: начинаем с 625(!!!) пользователей и добавляем каждые 10 секунд еще столько же. Длительность теста 1 час.
Почему была выбрана цифра 625 для меня до сих пор загадка. Данный тест показал что за час не удалось полностью успешно завершиться ни одному (!) пользователю. Все отработали с ошибками.
В результате долгих обсуждение и обдумывания полученных результатов была попытка изменить профиль.
375 пользователей и добавлять столько же каждые 2 секунды. Длительность выполнения теста 30 минут.
Я не понимаю на что они надеялись поменяв параметры теста таким образом. Но на удивление результат работы был следующим: есть успешно выполненные, но среднее время выполнения сценария около 24 минут. Фактически полностью успешно выполнялись только те, что стартовали вначале.
Провал
В результате клиент был не удовлетворен результатами тестирования. Долгое время выполнения сценария, максимальное количество одновременно работающих пользователей составляло всего 500. Дальше начались отказы в доступе - 503 ошибки сервера.
Не загружались требуемые ресурсы, не загружались динамически изменяемые данные. Все это можно было увидеть пройдя сценарий в ручном режиме при работающем тесте. Заказчики попробовали динамически добавлять сервера, но скорость их развертывания оказалась намного ниже скорости добавления пользователей. Иногда страницы загружались, но без CSS и картинок страницы выглядели примерно как
При таком отображении для рядового пользователя работать было не возможно. В результате тест был признан провалившимся. Web - система не смогла выдержать требуемую нагрузку. Проблема заключалась в том, что данная технология создавала большое количество подключений и удерживала их долго время. И чем больше пользователей прибывало, тем быстрее заканчивались существующие ресурсы. Но заказчику в любом случае необходимо было реализовать web-систему и предоставить ее на всеобщее обозрение.
Web-система. Ver. 2.0
Более недели мы не получали от них никакой информации. Они к нам вернулись с полностью переработанным движком системы.
Дизайн остался старый, те же переходы по вкладкам, те же картинки. Но был выполнен отказ от динамической загрузки данных, отказались от технологии WebSocket. Все необходимые данные загружались при загрузке первой страницы. Переходы по вкладкам были выполнены с помощью JS и отображались исключительно на стороне пользователя системы. Данные теперь отправлялись единожды общим пакетом, когда опрос был полностью пройден и нажата необходимая кнопка. Единственным дополнительным переходом осталась загрузка другого языка при его смене. Таким образом они сократили количество используемых соединений с сервером во много раз.
Мы все переделали. Уж теперь точно полетит…?!
Попробовали выполнять более агрессивные профили нагрузки. Сразу запускали 20 000 пользователей, потом 10 000. Но такое большое количество одновременно подключаемых пользователей заваливало сервер сразу же. Новые сервера опять же не успевали загружаться. В результате длительных дискуссий пришли к следующему профилю нагрузки: 150 пользователей и добавлять по 150 каждые 5 секунд. Длительность теста 40 минут.
В результате среднее время выполнения сценария 1 минута 20 секунд. Удалось значительно снизить количество ошибок подключения к Web-системе.
Да, теперь первая страница грузится дольше, чем в первом варианте. Но время выполнения всего сценария сократилось с 22 минут до 1 минуты и 20 секунд. Сервера начинали выдавать ошибки 503 только когда количество одновременно работающих пользователей перешло отметку в 5 000. Таким образом количество пользователей увеличилось в 10 раз с 500 до 5 000.
Времени для дальнейшей оптимизации уже не оставалось, т.к. через 2 дня у клиентов был релиз.
Результат
В результате ими принято решение признать тест успешным. Им не удалось достичь показателя в 50 - 60 секунд на один сценарий, им не удалось достичь 42 000 пользователей. Но они смогли сократить среднее время выполнения сценария и увеличить количество одновременно работающих пользователей в один момент времени.
Заключение
В заключение хочется отметить два момента.
В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать. В указанном мной случае исполнение кода JS на стороне клиента оказалось на много производительнее, чем исполнение кода на стороне сервера от множества пользователей.
Естественно я не отрицаю и таких вариантов, приложение спроектировано таким образом, что на сервере операции будут работать лучше и безопасность будет выше.
Иногда наши ожидания возможностей системы не всегда совпадают с реальностью. И в этом случае следует очень глубоко анализировать получаемые данные. Возможно стоит пересмотреть критерии оценки работоспособности системы, использовать другие метрики для ее измерения. Зачастую наши ожидания не совпадают с реальностью. Но это не означает что система работает не правильно или не справится с требуемой нагрузкой.
А может быть тестируемая нагрузка слишком избыточна и мы должны рассматривать несколько ее вариантов. Пробовать разные профили нагрузки.
Как тестировщик, хочу пожелать удачи вам в планировании и анализе результатов ваших нагрузочных тестов. Только вы определяете по каким критериям система будет признана успешной, а по каким будет провальной.
