Pull to refresh

Comments 15

Обратите внимание, что эта статья расписывает подробнее процесс тестирования, чем та, которую предложили вы.
Честно говоря статья никак не описывает «процесс тестирования». В процессе тестирования очень много нюансов помимо создания тестовго плана для нагрузочной станции:)

Здесь подробней чем в вашей и вышеупомянутых статьях:)
Для сравнения добавьте как то-же самое можно теоретически сделать с помощью ab.

Когда у нас на входе список URL`ов, а на выходе инфа по нагрузке.
ab не умеет список урлов. Только один URL. Или уже научился?
cat urls.txt | xargs ab ...

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

cat urls.txt | xargs -n 1 -P 100 wget -q
А результат (stdout) при этом никак не обрабатывается ведь? Интересно же на цифры посмотреть.
Но вообще чуднОй метод =)
Результат можно sed`ать и писать в некий лог, а потом с него нужное вытаскивать. Это лишь один из вариантов. Но я верю, что такое также вполне возможно.
Примитивный сценарий у вас получился, однако. Добавили бы хоть инфы про тестовую модель.

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

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

Из рекомендаций по самому жметру: пользоваться плагинами с гуглкода, вырубать на время теста (после отладки) tree view или ставить галку на сбор только ошибок.
Есть два разных вида нагрузки: scenario-based и hit-based. Здесь без задержек, и по сути это hit-based (лучше тут конечно использовать соотв. инструменты tsung/yandex-tank). Просто в таком тест-плане нужно оперировать не «виртуальными пользователями», а «хитами».

Ну это уже на выбор автора, чем и какой теорией и тактикой он хочет пользоваться. Разные способы для разных целей. Тут параметризации нет, можно и hit-based стрелять.

Для большего понимания разных техник hit/scenario и инструментов ab/siege/jmeter/yandex-tank просто оставлю ссылку тут
Да в любом тесте, кроме capacity, надо оперировать не виртуальными пользаками, а числом транзакций. Capacity же проводить без задержек нельзя. Собственно интернет-банки тоже в большинстве случаев мягко говоря не стоит так тестировать.

Модель теста кривовата и наверняка не соответствует поставленным задачам.
Ну мы же не только банки тестируем;-)
Ставить таймеры можно только в сценарных тестах нагрузки. Зависит от цели тестирования, не всегда вообще нужны «транзакции». Есть разные виды нагрузки, есть разные цели нагрузки. В банках и гос. конторах конечно в приоритете транзакции:)
Речь то как раз была про интернет-банк.

Вообщем, исходя из наблюдений, большинство шишек люди набивают из-за непонимания подходов к проведению НТ. Инструменты дело второе.
Я что-то не вижу контекст банкинга в статье :)
Ребята, пользуйтесь нормальными графиками jmeter-plugins. Ну невозможно же смотреть на этот хаос точек:)

Старайтесь обходить стороной аггрегирующие компоненты. (Aggregate Graph) и т.п. Для его работы необходимо в памяти держать данные о каждом выстреле, что критично, когда растет время теста. Используйте jtl для записи, а потом просто его анализируйте для отчетов. Производительно будет выше:)
Sign up to leave a comment.

Articles