Сообщений в теме: 11

[Case]

Описание подхода к тестированию производительности ПО
Автор: Андрей Широбоков
Библиотека / Тестирование ПО

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

[Dmitry_NJ]

Добавлю пару вещей от себя.

1. После того, как скрипты отлажены в самом туле, который используется для их создания, и ДО начала выполнения каких-либо реальных тестов, очень рекомендуется сделать калибровку, т.е. запустить разработанные скрипты с 3-5 виртуальными юзерами. Цель в данном случае посмотреть не на приложение, а посмотреть на скрипты - они не должны падать при работе в multi-user режиме.

2. Измерять CPU/Мemory это, конечно, надо, но гораздо важнее мониторить специфические параметры самого софта, который обслуживает приложение - web/app/DB серверов. Именно в значениях этих параметров под нагрузкой, как правило, можно увидеть потенциальный bottleneck. А CPU/Memory просто будут повышаться при увеличении нагрузки естественным образом. Это надо очень сильно промахнуться с HW, чтобы именно из-за него приложение не смогло нормально функционировать.

[Andre]

Дмитрий, спасибо за дополнения! Второй пункт вообще вполне заслуживает отдельной темы. Имея опыт с мониторингом и настройками связанными с производительностью для серверов баз данных Oracle и MS SQL, могу сказать что по каждому из них можно написать отдельную статью (описать что мониторить, что влияет на производительность и т.д).

С уважением,
Андрей Широбоков

[a66at]

Цель в данном случае посмотреть не на приложение, а посмотреть на скрипты - они не должны падать при работе в multi-user режиме.

А я опять пооппонирую. При описании общего подхода, вряд ли стоит заморачиваться на проблемы с потокобезопасностью в отдельно взятом Мерседесе. ;)

[a66at]

Кстати, привет, Андрей.

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

Тема масштабирования базы, выбора тестовых данных, кеширования и их взаимосвязи как-то слишком стыдливо раскрыта. На текущем этапе, насколько я могу судить именно это мешает отрасли двигаться к новым вершинам, т.к. в планах время на это не выделяется.

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

[Andre]

(to a66at) Виктор привет! Рад видеть :)!

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

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

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

[Dmitry_NJ]

При описании общего подхода, вряд ли стоит заморачиваться на проблемы с потокобезопасностью в отдельно взятом Мерседесе. ;)

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

[a66at]

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

Мне кажется это неубедительно. Неясно тогда откуда взялось число 3. Единственный раз, когда встречался с проблемой такого рода, это когда в данных unique параметра стало не хватать на всех пользователей и пришлось вспоминать как его дополнить. Подобная калибровка от этого не помогла бы. Чем она отличается от того, чтобы просто начать тестирование и внимательно посмотреть первый результат?

[Dmitry_NJ]

Мне кажется это неубедительно. Неясно тогда откуда взялось число 3.

Число 3-5 пользователей для калибровки взялось из практического опыта, накопленного в Mercury за долгие годы выполнения самых разнообразных проектов по нагрузочному тестированию по всему миру. Образно выражаясь, это "рекомендации лучших собаководов". Если вам кажется это неубедительным, то вам не надо это делать. Только и всего.

Единственный раз, когда встречался с проблемой такого рода, это когда в данных unique параметра стало не хватать на всех пользователей и пришлось вспоминать как его дополнить. Подобная калибровка от этого не помогла бы.

А калибровка это не серебряная пуля, которая убивает все возможные ошибки. Это просто еще один способ протестировать работоспособность скриптов перед их реальным использованием. Мне это помогло, например, в случае когда каждый пользователь на каждой итерации должен был брать новое значение параметра. Так что при 5 итерациях первый пользователь на первой итерации берет значение #1, второй пользователь на первой итерации берет значение #6, а не #2 и т.д. Помогало и в обнаружении проблем с использованием удаленных load generators.

Чем она отличается от того, чтобы просто начать тестирование и внимательно посмотреть первый результат?

Тем же, чем разработка и отладка отличаются от использования в боевых условиях. При калибровке в отличие от реального тестирования я могу включить самый полный логгинг, какой мне только нужен; я могу прогнать пару итераций, а не 10, которые требуются при реальном тестировании; я могу дать калибровочному тесту пробежать 5 минут, а не 2 часа, как мне нужно при реальном тестировании; я могу наплевать на настройку мониторов, потому что при калибровке меня не интересует тестируемая система.

Кроме того, частенько бывает так, что для тестирования выделяются только специальные окна (например, ночью) и вы не можете днем напустить на систему сотню-другую виртуальных юзеров, а 3-5 - без проблем. Это дает дополнительную уверенность в надежности скриптов и в более эффективном использовании времени, выделяемого для проведения реального тестирования.

[Yury]

Мне кажется это неубедительно. Неясно тогда откуда взялось число 3.

Две причины:
1) Проверка конкурентной работы скриптов (что уже было объяснено Dmitry_NJ)
2) Первый настоящий тест под нагрузкой.
Дело в том, что программисты умеют считать только до двух.
Когда им нужно отладить систему, расчитанную на конкурентную обработку, то они проверяют для одного пользователя и для двух пользователей.
При этом они верят, что если для двух пользователей всё работало хорошо, то всё будет работать хорошо и для многих тысяч.
Иногда система перестаёт работать уже при трёх конкурентных пользователях (в моей практике это встречалось дважды).

Юрий

[a66at]

Число 3-5 пользователей для калибровки взялось из практического опыта, накопленного в Mercury за долгие годы выполнения самых разнообразных проектов по нагрузочному тестированию по всему миру.

Ладно. Поскольку, на мой взгляд это не самая важная тема, не буду больше гнать волну, про полное логирование и ночные запуски звучит достаточно убедительно. Только один последний наводящий вопрос: оно прямо в документации или в чек-листах так написано, проводить калибровочный запуск? Мне кажется, что это отражение проблем конкретного тула, но переубеждать весь мир я не намерен.

Дело в том, что программисты умеют считать только до двух.

А причём тут вообще программисты? Речь идёт о конкуренции в тестовых скриптах. К тому же, всё познаётся в сравнении.

[Dmitry_NJ]

Только один последний наводящий вопрос: оно прямо в документации или в чек-листах так написано, проводить калибровочный запуск?

Калибровочный запуск это best practices. Это не является обязательным при использовании LR, посему в документации об этом ничего не написано. У нас есть Best Practices по продуктам, вот там об этом можно прочитать. Также должно быть упоминание про калибровку в LR training course.