Как проводится нагрузочное тестирование на проекте?

Question

[Katya007]

С какой периодичностью проводится нагрузочное тестирование на проекте?

Answer 1

[Araya]

Однозначного ответа нет, на каждом проекте могут проводить по-разному, например:
- После каждого релиза
- После определенного релиза (например добавили новую ручку/сервис и тд)
- С некой периодичностью (например каждую пятницу)
- Просто потому что...

Comments

[Сергей Горностаев]

Многие вообще не делают его никогда.

[Araya]

Сергей Горностаев, и это наверняка самый популярный вариант

[Lynn «Кофеман»]

Сергей Горностаев,

> Многие вообще не делают его никогда.

делают в продакшне силами пользователей :-)

Answer 2

[rPman]

Непрерывно! но не тестирование а мониторинг уже имеющейся нагрузки.

Сравнение нагрузочных метрик из операционной системы (нагрузка на процессор, память, диск и сеть) с количественными характеристиками - количество пользователей, их активность (включая вне сайта, например оплата), запросы к веб серверу, количество отказов и ошибок.

Читал что поверх собранной статистики (чем подробнее тем лучше) собирают небольшую нейронку, выявляющую нетипичные паттерны, это помогает заранее выявить даже атаки (тот же ддос и автоматизации), прогнозировать будущую нагрузку и оперативно аапгрейдить железо/добавлять нод в кластер.

p.s. как только ты выходишь на некоторый порог количества пользователей, то каждый твой апдейт (даже если тебе кажется что это ничего важного не затрагивает) должен проходить полное тестирование в специальной песочнице (именно поэтому нужна автоматизация, но и ручное не забывают), и в качестве одного из шагов, тяжелый функционал тестируют синтетической нагрузкой, создаваемой на основе мониторинга реальной.

Comments

[Q2W]

но не тестирование а мониторинг

И не выиграл, а проиграл)
P.S.: простите, не удержался

Answer 3

[Vitsliputsli]

Прям очень по-разному, но чаще очень редко или никогда.
Вообще, нагрузочное бывает 2х видов:
1) тестирование релиза на возможную деградацию производительности;
2) тестирование запаса прочности приложения (это когда повышаем нагрузку, пока все не упадет).
И еще важно где применяется:
а) где деплой полностью контролируется, т.е. на свои серверы;
б) где сборка разворачивается где-то на удаленных серверах 3ми лицами.
Нагрузочное 1 типа для варианта "б" проводят для каждого билда, вряд ли есть исключения, иначе чревато. Для варианта "а" часто "забивают" вообще на этот тип тестирования. Причины просты, прям какаято сильная деградация будет заметна при прогоне обычных тестов, просто по их замедлению. А если тесты еще идут параллельными потоками, то и некоторые блокировки можно отловить. С другой стороны, если чтото не так, то деплой полностью контролируется и можно всегда откатиться. И тут реально в первую очередь лучше озаботиться blue-green серверами и плавным переключением трафика, а потом уже нагрузочным тестированием. Да и чаще, это будут какието медленные деградации, которые отловит мониторинг и опять же либо будет время поправить, либо можно откатиться.
Нагрузочное типа 2 делают очень редко (например 1-2 раза в год), т.к. штука затратная, и опять же мало где его вообще встретишь, только там где стабильность очень важна и/или пиковая нагрузка может в разы отличаться от стандартной.

Answer 4

[Василий Банников]

У нас на проекте нагрузочное обязательно проводят перед каждым релизом как часть регрессионного тестирования.

Но у нас и соглашения с клиентами есть по скорости ответов, отсюда и необходимость проверять.

Думаю, если задать вопрос типа "а зачем в проекте нагрузочное тестирование", то тогда и по периодичности всё станет ясно.

Смотрим в тестах максимальную "прочность", сколько RPS можно держать без значительной деградации и стабильность - можем ли мы длительное время держать достаточно большую нагрузку (объем смотрим по пиковой нагрузке в проде)

+ к этому ещё и постоянный мониторинг времени ответа на проде.

Регресс, естественно, происходит в окружении близком к продовому.

+ ещё сейчас затащили нагрузочное тестирование в ci - там только смотрим, есть ли деградация по максимальной производительности. Там тестирования происходит уже в очень далёком от прода окружении, зато часто (на каждый MR)