понедельник, 9 мая 2022 г.

Нагрузочное тестирование

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


Вот, например, если я создам свою социальную сеть, в ней будет 3 калеки. А сколько человек каждый день заходят в инстаграмм? А в фейсбук? Сбербанк онлайн? Если у вас высоконагруженное приложение, то тестировать нагрузку просто обязательно. 

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

  • Данные могут побиться, деньги потеряться где-то посреди трансфера — со всем этим придется разбираться после того, как приложение поднимут.
  • Колл-центр завалят звонками — создадут высокую нагрузку уже на операторов.

Во время нагрузочного тестирования важно проверить:

  • Производительность — насколько шустро приложение работает под нагрузкой?
  • В какой момент наступит отказ?

См также: Тестирование производительности

Поэтому по результатам проведения теста строят похожую табличку:

Количество пользователей

Время ответа, с

Ошибок, %

1

0,01

0

100

0,1

2

1000

3

10

2000

n\a

100

Благодаря ей мы знаем, когда наступает отказ. Знаем, сколько ошибок будет для 100 или 1000 пользователей. И дальше уже думаем — устраивают нас эти цифры или нет?

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

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

  • Веб-сайт — сколько пользователей одновременно зайдет?
  • Обработка данных — сколько потоков одновременно работает?
  • API-интерфейс — сколько запросов идут в параллель?
  • ...


Если приложение нагруженное, то оптимизировать надо все. Не только циклы внутри кода, но и базу данных, и сервер приложения... Здесь пригодится помощь админов БД, которые смогут оптимизировать саму базу. Разработчики должны использовать хинты в коде и строить более оптимальные запросы. 

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


Пример из практики

В одном из проектов мы делали систему хранения и обработки данных — вот есть в банке 10 разных систем: 

  • Когда человек пришел ножками в банк, оператор вносит его в систему 1
  • Когда он заполнил онлайн-заявку, попадает в систему 2
  • Когда он позвонил в call-centre, попадает в систему 3

В итоге в одной системе есть паспорт, в другой емейл, в третьей телефон. А мы объединяем все эти данные в одну «золотую» запись, максимально заполненную. Попутно исправляя опечатки ввода =)

Данные поступают двумя путями:

— через базу данных;

— через онлайн-методы (SOAP, REST).

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

Нагрузка и стресс идут рука об руку. Для нашей системы загрузка 150 млн была стрессовой ситуацией, отсюда и название стенда. Загрузили 1 раз, оптимизировали всё, что только возможно, перегрузили снова, замерили результаты.

А потом сделали на этом стенде постоянный нагрузочный тест:


1. Забор из БД — инкремент на 150 тысяч:

— создание 50 тыс (insert);

— обновление 50 тыс (update);

— удаление 50 тыс (delete);

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

Если бы проверялось только создание новых карточек, мы могли бы пропустить проблемы и просадку производительности в каких-то случаях. Скажем, удаление из «толстой» карточки (объединена из 10 других) стало идти несколько минут, а мы такое не тестируем!

Стройте нагрузочный тест с умом. Задействуйте все возможные операции. В первую очередь — CRUD!




2. Запросы через SOAP

— create

— update

— getByName

— getByPhone

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

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

Нагрузка по API передается через JMeter. Забор из БД — разработчик сгенерировал задачу, которую нужно включить вручную в админке (или настроить триггер автозапуска).


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



Инструменты


Для создания нагрузки есть много инструментов:

  • Apache JMeter
  • LoadSophia
  • HP Load Runner
  • Load Impact

Самый популярный — это JMeter. Он бесплатный и довольно удобный. Ну а дальше уже, если интересно развиваться в этой области — гугл в помощь =) Пробуйте разные инструменты и выбирайте тот, который подойдет под вашу задачу.


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

Комментариев нет:

Отправить комментарий