Как вы тестируете приложение?

Каков наиболее эффективный способ загрузки и тестирования вашего приложения? Суть в том, чтобы определить, сколько пользователей вы могли бы поддерживать одновременно, если приложение все еще работает с разумной скоростью.

Самым полным программным обеспечением для нагрузочного тестирования, которое я нашел, является HP LoadRunner (извините за ссылку bit.ly, но ссылка HP ужасна и не будет работать правильно). Он очень гибкий, и вы можете создавать множество различных типов отчетов из нагрузочных тестов. Вы также можете иметь группу машин, работающих в тандеме для загрузки теста. Не то чтобы другие инструменты плохие, но это делает что-то вроде Apache JMeter похожим на игрушку.

httperf главным образом, а также AB инструмент тестирования Apache

(и тонны инструментов для отлова повторяющихся запросов и ошибок кэширования.)

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

Если вы хотите стать действительно модным, вы можете записывать и воспроизводить HTTP-трафик с помощью httperf.

Microsoft Web Capacity Analysis Tool (WCAT), как сообщается, является инструментом выбора команды IIS.

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

1. Будет ли он использовать мои интерфейсы в моем приложении? Есть много инструментов, которые бесплатны, но интерфейс монолитен и может не использовать ваше приложение в полной мере. Коммерческие инструменты имеют более широкую поддержку протоколов / интерфейсов, чем открытые.
2. Будет ли отчетность соответствовать моим потребностям? Нет ничего более расстраивающего, чем запуск теста и необходимость потратить дни на то, чтобы собрать результаты в какую-то значимую форму для анализа и определения того, выполнили ли вы свои требования или нет. Еще раз, это область, где коммерческие инструменты побеждают сопли из открытых источников.
3. У моей команды есть технические навыки, чтобы использовать инструмент? Вы не хотите преодолевать препятствия или одновременно тестировать производительность, анализировать и еще один язык / инструмент для одновременного изучения. Быть реалистичным.
4. Будет ли он работать на моей тестовой инфраструктуре? Проверьте требования. Если указана конкретная ОС и версия, используйте ее или не используйте инструмент. Меньше вещей разочаровывают в поддержке инструментов, когда кто-то звонит / отправляет электронное письмо с проблемой только для того, чтобы обнаружить, что требования к установке и эксплуатации были проигнорированы.

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

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

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