Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 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 для записи, а потом просто его анализируйте для отчетов. Производительно будет выше:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации