Большой вопрос.Мы несколько лет проводили тесты производительности и нагрузочные тесты в моей компании, в основном на основе HTTP.
Прежде чем перейти к сложным сценариям, мы часто начинаем с простых тестов производительности, основанных на Apache Bench ('команда ab 'в комплекте с Apache).Это не нагрузочный тест, а тест производительности, поскольку сгенерированный клиент фактически ожидает завершения HTTP-запроса, прежде чем перейти к следующему.Основная идея состоит в том, чтобы попробовать 'ab -c N -t 30' с N = 1,2,4,8,50,100 (например).Вы быстро получите представление о масштабируемости и ожидаемой максимальной пропускной способности.
Примечание : выполните команду ab рядом с тестовым сервером (в идеале в той же локальной сети), в противном случае вытакже проведу тестирование сети (задержка является главной проблемой здесь).Но в некоторых бизнес-случаях это общая система (сервер + сеть), которая действительно предназначена для тестирования.
Отсюда, если результаты выглядят хорошими (т. Е. Объем обработки увеличивается до числа процессоров вна стороне сервера, низкий или нулевой уровень ошибок), приступим к нагрузочному тестированию.В противном случае мы ищем узкие места , поскольку нагрузочный тест подтвердит проблему масштабируемости и , наиболее вероятно, покажут ужасные результаты, когда нагрузка будет превышать поддерживаемую пропускную способность (100% из 500 внутренних ошибок,разрывы соединения, большие тайм-ауты, перебои в работе сервера и т. д.).
Кстати, под нагрузочным тестированием я имею в виду использование инструментов, которые могут применять любую нагрузку на данный сервер / приложение , особенно нагрузку на серверне может справиться (например: Jmeter, Tsung).В нагрузочном тесте очень интересно наблюдать за тем, что происходит, когда сервер перегружен.Определение максимальной нагрузки, которую может обрабатывать сервер, зависит от вас, когда вы выбираете точную контрольную точку, в которой производительность не считается приемлемой.
Тогда необходимо угадать или наблюдать существующие шаблоны.Во многих случаях нас просят выполнить нагрузочный тест для нового веб-сайта, где, очевидно, никакого реального поведения не наблюдается.В противном случае вы можете использовать аналитику и просмотреть первые десять страниц: ваш сценарий должен по крайней мере пройти их.Вам понадобятся несколько навигационных путей, которые:
- явно доходят до домашней страницы
- используют функцию поиска и переходят от одного контента к другому, может быть случайным образом
- перейти к входу в систему, если функция существует
- в более общем смысле использовать POST-формы, при нагрузочной проверке которых только чтение / получение данных не имеют особого значения
Другие советы:
- избегать сложности;например, если у вас есть корзина для покупок, вам не нужно настраивать реальный сценарий покупок с помощью оплаты и др.В интернет-магазине путь к корзине покупок редко является проблемой производительности, 95% трафика приходится на другие места (просмотр товаров и т. Д.).
- тестируйте пути навигации по одному, прежде чем складывать их в один большойнагрузочный тест фиеста;они должны заранее обеспечить хороший результат по отдельности
- лучше указать множество путей для реального использования кэшей (всегда есть кэши: HTTP, app, SQL, файловая система и т. д.);инструменты, которые генерируют динамические сценарии, в которых вы можете изменять имена входа или идентификаторы объектов из длинных списков, являются обязательными
Общая идея заключается в том, чтобы делать это постепенно, начиная с простых тестов, в противном случае у вас будет сложныйвремя интерпретировать результат, если они не соответствуют идеальной кривой масштабируемости.И угадай что?Они никогда не соответствуют идеальной кривой масштабируемости ...