Мы обсудили инструменты, используемые для грузить тестирование здесь, на ServerFault, но как насчет обучения их правильному использованию? Есть ли компании, специализирующиеся на ИТ-обучении и охватывающие нагрузочное тестирование? Как правильно придумать имитацию нагрузки? Как долго нужно проводить тест? Какие показатели лучше всего отслеживать на стороне сервера во время выполнения теста? И так далее...
Во-первых, начнем с представителей бизнеса. Они (должны) лучше знать приложение. Определите ключевые транзакции и время ответа от начала до конца. В идеале они смогут вручить вам документ, отражающий их нефункциональные требования. Если ваше приложение заменяет устаревшее приложение, тем лучше - получите как можно больше применимых метрик использования из этого приложения. Это наиболее важный фактор успеха при тестировании производительности. Понимание размера вашей потенциальной базы пользователей, количества пользователей, которые, вероятно, будут использовать ее одновременно, #% каждой из ваших ключевых транзакций, выполняемых одновременно, темпа роста за [временной интервал].
Создайте автоматизированный скрипт, имитирующий ключевые транзакции. Включите время обдумывания в этот сценарий. Очень немногие пользователи будут запускать ваше приложение / веб-сайт, не потратив несколько секунд, чтобы увидеть, что приложение сделало в ответ на их ввод. Неспособность адекватно смоделировать время обдумывания может привести к тому, что ваше приложение будет загружено нереально, что приведет к несчастью для всех. При этом бизнес может определить, что 10% пользовательской базы - это опытные пользователи, и вы можете захотеть доставить свою нагрузку с помощью 90% обычных пользователей с `` нормальным '' временем обдумывания и 10% опытных пользователей с более быстрыми и агрессивными подумайте раз.
Добавьте своих виртуальных пользователей в течение определенного периода времени (время нарастания) - не переходите с 0 до 500 за 1 секунду, если только у вас действительно не будет такой нагрузки (продажа начинается в 9:00!). Хорошо понимать, как ваше приложение будет вести себя при скачках нагрузки, но некоторые приложения могут отказывать в этих сценариях, что является проблемой только в том случае, если вы ожидаете такой нагрузки. В противном случае вы можете обнаружить, что тратите намного больше денег, чем требуется для поддержки нагрузки, которая может никогда не наступить.
Фактор задержки и скорости сети. Для стресс-теста отлично иметь соединение Gigabit Ethernet с задержкой менее 1 мс для вашего приложения, которое вы можете использовать, чтобы подтолкнуть свое приложение, чтобы определить, когда оно выйдет из строя. На самом деле, однако, ваши пользователи обычно не так уж близки к вашему приложению - они сталкиваются с различными типами сетевых условий.
Тестирование на выносливость - рекомендуется не менее 24 часов, или больше, если вы можете себе это позволить. Вы хотите фиксировать, что происходит с вашим приложением при запуске периодических пакетных процессов, таких как резервное копирование, обновление определений антивируса или даже перезапуск пула приложений IIS (по умолчанию каждые 29 часов).
Поймите разницу между тестированием производительности и нагрузочным тестированием. Нагрузочные тесты обычно показывают перспективу сервера. Это не совсем так - многие инструменты покажут вам время, необходимое для транзакции с точки зрения TTLB, но большинство инструментов сегодня не отражают время рендеринга на стороне клиента, которое является существенным в приложениях с большим количеством JS или тех, которые используют XSLT. , например.
Не полагайтесь исключительно на числа ваших автоматических тестов - по крайней мере, не начиная с первого дня. Периодически вручную проверяйте полученные числа. Со временем вы можете позволить этому утихнуть, когда вы станете более уверенными в своих симуляциях.
Счетчики производительности - каждое приложение будет отличаться, но вы не ошибетесь, начав с четырех основных групп продуктов - ЦП, память, дисковый ввод-вывод, сетевой ввод-вывод. Список моих предпочтительных счетчиков находится на ht tp: //www.oneredlight.com/perf.config.txt. Вы можете настроить приложение для регистрации этих счетчиков в кольцевом файле размером 300 МБ с помощью следующей командной строки: logman create counter PERF -f bincirc -max 300 -si 2 --v -o "c: \ perflogs \ perf" -cf "perf.config". Я пробовал их только на Windows 2008 / IIS 7 / SQL 2008, поэтому ваш опыт может отличаться. Я также рекомендовал бы прочитать ht tp: //msdn.microsoft.com/en-us/library/ms998530.aspx, если ваше приложение находится в стеке ms.
(извинения за неработающие URL; новые пользователи не могут размещать гиперссылки)