Нагрузка — возможность одновременной работы с приложением большого числа пользователей.
Вот, например, если я создам свою социальную сеть, в ней будет 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. Он бесплатный и довольно удобный. Ну а дальше уже, если интересно развиваться в этой области — гугл в помощь =) Пробуйте разные инструменты и выбирайте тот, который подойдет под вашу задачу.
Комментариев нет:
Отправить комментарий