Тренинг для нагрузочного тестирования веб-приложений?

1. Сначала начнем с представителей бизнеса. Они (должны) знать приложение лучше всего. Определите ключевые транзакции и время окончания ответа. В идеале, они смогут вручить вам документ, который отражает их нефункциональные требования. Если ваше приложение заменяет устаревшее приложение, тем лучше - получите как можно больше применимых метрик использования из этого приложения. Это наиболее важный фактор успеха при тестировании производительности. Понимая размер вашей потенциальной пользовательской базы, количество пользователей, которые могут ее использовать одновременно, # % каждой из ваших ключевых транзакций, выполняемых одновременно, скорость роста за [таймфрейм].

2. Создайте автоматический скрипт, который имитирует ключевые транзакции. Включите время обдумывания в этот скрипт. Очень немногие пользователи собираются включить ваше приложение / веб-сайт без необходимости тратить несколько секунд, чтобы увидеть, что приложение сделало в ответ на их ввод. Неспособность адекватно имитировать время на размышление может привести к тому, что ваше приложение подвергнется нереалистичной нагрузке, что повлечет за собой несчастные случаи вокруг. При этом компания может определить, что 10% пользователей являются опытными пользователями, и вы, возможно, захотите предоставить свою нагрузку 90% обычных пользователей, с "нормальным" временем обдумывания и 10% опытных пользователей, с более быстрыми и агрессивными действиями. подумай раз.

3. Добавьте своих виртуальных пользователей за период времени (время разгона) - не переходите от 0-500 за 1 секунду, если только у вас фактически не будет такой нагрузки (продажа начинается в 9:00!). Хорошо понимать, как ваше приложение будет вести себя при скачках нагрузки, но некоторые приложения могут не работать в этих сценариях, что является проблемой только в том случае, если вы ожидаете такой нагрузки. В противном случае вы можете потратить гораздо больше денег, чем требуется для поддержки нагрузки, которая может никогда не прийти.

4. Фактор задержки и скорости сети. Для стресс-теста очень важно иметь гигабитное соединение Ethernet с задержкой менее 1 мс к вашему приложению, которое вы можете использовать, чтобы подтолкнуть ваше приложение, чтобы определить, когда оно выйдет из строя. В действительности, однако, ваши пользователи обычно не так близки к вашему приложению - они сталкиваются с различными типами сетевых условий.

5. Тест на выносливость - рекомендуется минимум 24 часа, больше, если вы можете себе это позволить. Вы хотите получить информацию о том, что происходит с вашим приложением при выполнении периодических пакетных процессов, таких как резервное копирование, обновление определений антивируса или даже повторение пулов приложений IIS (по умолчанию каждые 29 часов).

6. Понять разницу между тестированием производительности и нагрузочным тестированием. Нагрузочные тесты обычно показывают перспективу сервера. Это не совсем так - многие инструменты будут показывать вам время, затрачиваемое на транзакцию в терминах TTLB, - но большинство инструментов сегодня не отражают время рендеринга на стороне клиента, которое является существенным в приложениях с интенсивным использованием JS или тех, которые используют XSLT., например.

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

8. Счетчики производительности - каждое приложение будет отличаться, но вы не ошибетесь, если начнете с четырех основных групп продуктов: процессор, память, дисковый ввод-вывод, сетевой ввод-вывод. Список моих предпочтительных счетчиков находится по адресу 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; новые пользователи не могут публиковать гиперссылки)