Выполняете стресс-тест веб-приложения?

Я использовал Точильщик. Это открытый исходный код, довольно простой в использовании и легко настраиваемый. Он основан на Java и использует Jython для скриптов. Мы запускали его с веб-приложением .NET, поэтому не думайте, что это инструмент, предназначенный только для Java (по своей природе любой веб-инструмент стресса не должен быть привязан к платформе, которую он использует).

Мы проделали с ним кое-что интересное ... мы были веб-приложением для телекоммуникаций, поэтому я установил одно интересное использование - имитировать набор номера через наше веб-приложение, а затем использовать инструмент автоответа, который у нас был (который, по сути, был учебным пособием). приложение от Microsoft для подключения к их серверу RTC LCS ... это то, к чему Microsoft Office Communicator подключается в локальной сети ... затем изменено, чтобы просто автоматически принимать вызовы). Это позволило нам использовать его вместо дорогостоящего инструмента телефонии под названием The Hammer (или чего-то подобного).

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

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

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

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

Взгляните на TestComplete.

Я обнаружил, что IBM Page Detailer также является интересным инструментом для работы.

Я использовал openSTA.

Это позволяет записывать сеанс с веб-сайтом, а затем воспроизводить его на относительно простом языке сценариев.

Вы можете легко протестировать веб-службы и написать свои собственные сценарии.

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

Это открытый исходный код и бесплатный.

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

Вот еще один голос за JMeter.

JMeter - это инструмент нагрузочного тестирования с открытым исходным кодом, написанный на Java. Он способен тестировать ряд различных типов серверов (например, веб, веб-службы, базы данных, практически все, что в основном использует запросы).

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

Плюсы:

• Инструмент с открытым исходным кодом / бесплатный из проекта Apache (помогает с покупкой)
• Легко начать работу и легко использовать, как только вы усвоите основные концепции. (Т.е. как создать запрос, как создать утверждение, как работать с переменными и т. д.).
• Очень масштабируемый. Я провел тесты с 11 машинами, генерирующими нагрузку на сервер почти в миллион обращений в час. много настроить было проще, чем я ожидал.
• Имеет активное сообщество и хорошие ресурсы, которые помогут вам начать работу. Сначала прочтите руководства и поиграйте с ними некоторое время.

Минусы:

• Пользовательский интерфейс написан на Swing. (фу!)
• JMeter работает, анализируя текст ответа, возвращаемый сервером. Так что, если вы хотите проверить какое-либо поведение javascript, вам не повезло.
• Кривая обучения для непрограммистов очень крутая. Если вы знакомы с регулярными выражениями, вы уже впереди всех.
• На форуме поддержки много идиотов (вставить ненормативную лексику), задающих глупые вопросы, которые можно было бы легко решить, если бы они бегло просмотрели документацию. («Как использовать JMeter для стресс-тестирования графического интерфейса Windows» появляется довольно часто).
• Отчетность «из коробки» оставляет желать лучшего, особенно для более крупных тестов. В тесте, о котором я упоминал выше, мне пришлось написать быстрое консольное приложение для выполнения некоторых преобразований из «xml-logfile» в «html». Однако это было несколько лет назад, поэтому, вероятно, в этом больше не будет необходимости.

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

Мы используем упомянутый инструмент Microsoft - Microsoft Web Application Stress Tool. Это самый простой инструмент, который я использовал. Он ограничен многими способами, в том числе возможностью попасть на порт 80 только в тестах, созданных вручную. Но простота использования означает, что к нему действительно привыкли.

Мы дополняем нагрузку от этого инструмента другими инструментами, включая OpenSTA и пауков проверки ссылок.

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

Я предлагаю открыть еще один вопрос относительно интерпретации результатов инструмента для снятия стресса от РС.

Я попробовал WebLoad, это довольно интересный инструмент. Он поставляется с IDE тестового сценария, который позволяет записывать действия пользователя на веб-сайте. Он также рисует график при выполнении стресс-теста на вашем веб-сервере. Попробуйте, очень рекомендую.

Я играл с JMeter. Считалось, что его невозможно протестировать, так это ASP.NET Webforms. Состояние просмотра сломало мои тесты. Я не уверен, почему, но есть пара инструментов, которые неправильно обрабатывают состояние просмотра. Мой текущий проект - ASP.NET MVC, и JMeter хорошо с ним работает.

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

Тем не менее, я также недавно решил, что вся концепция нагрузочного тестирования была ошибочной: эмуляция HTTP-трафика с приложениями, столь же сложными, как они стали, - это головная боль. Вот почему я создал коммерческий инструмент BrowserMob. Это сервис внешнего нагрузочного тестирования, который использует Селен для управления реальными веб-браузерами при воспроизведении нагрузки.

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

Извините за демонстрацию коммерческого продукта, но, надеюсь, концепция заинтересует некоторых людей и, по крайней мере, заставит их задуматься о некоторых новых способах работы с нагрузочным тестированием, когда у вас есть доступ к большому количеству дополнительного оборудования!

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

Visual Studio Test Edition 2010 (тоже хорошо 2008). Это действительно простой и мощный инструмент для создания веб / нагрузочных тестов.

Преимущество этого инструмента при использовании против серверов Windows заключается в том, что вы получаете интегрированный доступ ко всей статистике сервера perfmon в своем отчете. Действительно полезно.

Другой бонус заключается в том, что с проектом Visual Studio вы можете интегрировать «сеанс производительности», который будет профилировать выполнение кода вашего веб-сайта.

Если вы обслуживаете веб-страницы с сервера Windows, это лучший инструмент.

Однако для использования нескольких машин для нагрузочного тестирования приложения требуется отдельная и дорогая лицензия.

Для простого использования я предпочитаю ab (тест apache) и siege, позже он понадобится, так как ab не поддерживает файлы cookie и будет создавать бесконечные сеансы с динамического сайта.

и то, и другое просто начать:

ab -c n -t 30 url

siege -b -c n -t 30s url

Осада может работать с большим количеством URL-адресов.

последняя версия осады включается многословно в siegerc, что раздражает. вы можете отключить его, только отредактировав этот файл (/usr/local/etc/siegerc).

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

ab, осада, Цунг, httperf, Топтать, Pylot, анализатор журнала запросов, perftools

Это старый вопрос, но я думаю, что стоит упомянуть новые решения. Влияние нагрузки на кассу: http://www.loadimpact.com.

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

Итак, во время разработки мы включаем очень базовое многопользовательское тестирование (с использованием селена), которое проверяет базовое безумие, такое как управление прерванными сеансами, очевидные проблемы параллелизма и очевидные проблемы конкуренции за ресурсы. Нетривиальные проекты включают это в процесс непрерывной интеграции, поэтому мы получаем очень регулярную обратную связь.

Для проектов, которые не предъявляют экстремальных требований к производительности, мы включаем в наше тестирование базовое тестирование производительности; обычно мы создаем сценарии тестов с помощью BadBoy и импортируем их в JMeter, заменяя данные для входа и другие специфичные для потока вещи. Затем мы увеличиваем их до уровня, когда сервер обрабатывает 100 запросов в секунду; если время отклика меньше 1 секунды, этого обычно достаточно. Мы запускаем и двигаемся дальше по жизни.

Для проектов с экстремальными требованиями к производительности мы по-прежнему используем BadBoy и JMeter, но много сил вкладываем в понимание узких мест на серверах нашей тестовой установки (обычно веб-серверы и серверы баз данных). Есть хороший инструмент для анализа журналов событий Microsoft, который очень помогает в этом. Обычно мы обнаруживаем неожиданные узкие места, которые по возможности оптимизируем; это дает нам приложение, которое работает настолько быстро, насколько это возможно на «1 веб-сервере, 1 сервере базы данных». Затем мы обычно выполняем развертывание в нашей целевой инфраструктуре и используем одну из служб «Jmeter в облаке» для повторного запуска тестов в масштабе.

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

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

Здесь упоминается много хороших инструментов. Интересно, являются ли инструменты ответом на вопрос: «Как провести стресс-тестирование веб-приложения?» Эти инструменты на самом деле не предоставляют метода стресса для веб-приложения. Вот что я знаю:

Стресс-тестирование показывает, как веб-приложение дает сбой, обслуживая ответы все большего числа пользователей. Стресс-тестирование показывает, как работает веб-приложение в случае сбоя. Большинство современных веб-приложений, особенно социальных и мобильных веб-приложений, представляют собой интеграцию сервисов. Например, когда в мае 2011 года у Facebook был сбой, вы не могли войти в веб-приложение Pepsi.com. Приложение не вышло из строя полностью, просто большая часть его обычных функций стала недоступна для пользователей.

Тестирование производительности показывает способность веб-приложения поддерживать время отклика независимо от того, сколько пользователей одновременно используют приложение. Например, приложение, которое обрабатывает 10 транзакций в секунду с 10 одновременными пользователями, должно обрабатывать 20 транзакций в секунду у 20 пользователей. Если приложение обрабатывает менее 20 транзакций в секунду, время отклика увеличивается, и приложение не может достичь линейной масштабируемости.

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

Я написал методологию PushToTest в Руководстве пользователя TestMaker по адресу http://www.pushtotest.com/pushtotest-testmaker-6-methodology. TestMaker поставляется в двух вариантах: версия сообщества с открытым исходным кодом (GPL) и TestMaker Enterprise (коммерческая с отличной профессиональной поддержкой).

-Откровенный

У меня были хорошие результаты с FunkLoad:

• легко написать сценарий взаимодействия с пользователем
• отчеты ясны
• может контролировать нагрузку на сервер

Рискуя быть обвиненным в бессовестной саморекламе, хочу отметить, что в поисках бесплатного инструмента нагрузочного тестирования я обратился к этой статье: http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html

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

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

Вот он: http://sourceforge.net/projects/loadmonger

PS: Никаких ехидных комментариев к имени от людей, знакомых с городским сленгом. Я не был, но теперь стал немного более мирским.

Для веб-службы проверьте loader.io.

Резюме:

loader.io is a free load testing service that allows you to stress test your web-apps/apis with thousands of concurrent connections.

У них также есть API.

Поскольку этот вопрос все еще открыт, я мог бы также взвесить его.

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

Вот мои мысли: -

Jmeter против шлифовального станка

Jmeter основан на спецификации стиля XML, которая создается через графический интерфейс.

Grinder использует сценарии Jython в многопоточной среде Java, поэтому больше ориентирован на программистов.

Оба инструмента будут обрабатывать HTTP и HTTPS и иметь прокси-рекордер, чтобы вы могли начать работу. Оба инструмента используют модель контроллера для управления несколькими тестовыми агентами, поэтому масштабируемость не является проблемой (при наличии доступа к облаку).

Что лучше:-

Сложный вызов, поскольку кривая обучения является крутой с обоими инструментами, поскольку вы попадаете в более сложные требования к сценариям для переписывания URL-адресов, корреляции, предоставления уникальных данных для каждого виртуального пользователя и имитации первого раза или возврата пользователей (путем манипулирования заголовками HTTP).

Тем не менее, я бы начал с Jmeter, так как этот инструмент имеет огромное количество поклонников, и в Интернете есть много примеров и руководств по использованию этого инструмента. Если и когда вы попадаете в «преграду», это то, что вы не можете «легко» сделать с Jmeter, взгляните на Grinder. Хорошая новость заключается в том, что оба этих инструмента предъявляют одинаковые требования к Java, и не исключено решение «смешивать и сочетать».

Что-то новое, что нужно добавить - браузеры без головы, запускающие несколько экземпляров Selenium WebDriver.

Это относительно новый подход, потому что он полагается на доступность ресурсов, которые теперь могут быть предоставлены из облака. При таком подходе сценарий Selenium (WebDriver) берется и запускается в автономном браузере (например, в драйвере WebDriver = New HtmlUnitDriver ()) в нескольких потоках.

Опыт показывает, что из малого экземпляра Amazon M1 можно запустить около 25 экземпляров «браузеров без головы».

Это означает, что все корреляции и проблемы с переписыванием URL-адресов исчезают, когда вы перепрофилируете свои скрипты функционального тестирования в скрипты тестирования производительности.

Масштабируемость ставится под угрозу, поскольку для управления нагрузкой потребуется больше виртуальных машин по сравнению с драйвером HTTP, таким как Grinder или Jmeter. Тем не менее, если вы хотите привлечь 500 виртуальных пользователей, то с 20 небольшими инстансами Amazon (6 центов в час каждый) по цене всего 1,20 доллара в час вы получите нагрузку, очень близкую к реальному пользовательскому опыту.

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

Blaze meter имеет расширение Chrome для записи сеансов и их экспорта в JMeter (в настоящее время требуется вход в систему). У вас также есть возможность заплатить им деньги за запуск на их кластере серверов JMeter (их цены кажутся намного лучше, чем LoadImpact, который я только что перестал использовать):

• Расширение BlazeMeter Chrome
• Запись в блоге об этом

Никаких ассоциаций с ними не имею, мне просто нравится внешний вид их сервиса, хотя я еще не пользовался платной версией.

Недавно мы начали использовать Gatling для нагрузочного тестирования. Я очень рекомендую попробовать этот инструмент для нагрузочного тестирования. В прошлом мы использовали SOASTA и JMETER. Наша основная причина выбрать Gatling заключается в следующем:

• Регистратор для записи сценария
• Использование Akka и Netty, обеспечивающих лучшую производительность по сравнению с Модель резьбы Jmeter
• DSL Scala, который очень удобен в обслуживании по сравнению с Jmeter XML
• Тесты писать несложно, не пугайтесь, если это scala.
• Составление отчетов

Приведу простой пример написания кода с использованием кода Гатлинга:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Однако вы можете сделать это как можно сложнее. Одна из отличительных черт Gatling - это очень подробные отчеты.

Вот несколько ссылок:
Гатлинг
Учебник Гатлинга

Я недавно говорил об этом, вы можете прочитать доклад здесь:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gatling.pdf

Попробуйте ZebraTester, который намного проще в использовании, чем jMeter. Я использовал jMeter долгое время, но общее время настройки для нагрузочного теста всегда было проблемой. Хотя ZebraTester не является открытым исходным кодом, время, которое я сэкономил за последние шесть месяцев, компенсирует это. У них также есть портал SaaS, который можно использовать для быстрого выполнения тестов с использованием их генераторов нагрузки.

Взгляните на LoadBooster (https://www.loadbooster.com). Он использует браузер PhantomJS / CasperJs с безголовым скриптом для тестирования веб-сайтов. Phantomjs проанализирует и отобразит каждую страницу, выполнит клиентский скрипт. Подход с использованием безголового браузера проще для написания тестовых сценариев для поддержки сложных приложений AJAX Web 2.0 ， навигации в браузере, щелчка мыши и нажатия клавиш в браузере или ожидания, пока элемент не появится в DOM. LoadBooster также поддерживает selenium HTML-скрипт.

Отказ от ответственности: я работаю в LoadBooster.

Я тоже голосую за jMeter и хочу добавить несколько цитат к ответу @PeterBernier.

The main question that load testing answers is how many concurrent users can my web application support? In order to get a proper answer, load testing should represent real application usage, as close as possible.

Имейте в виду, что jMeter имеет множество строительных блоков Логические контроллеры, Элементы конфигурации, Предварительные процессоры, Слушатели, ... которые могут вам в этом помочь.

Вы можете имитировать реальную ситуацию с помощью jMeter, например, вы можете:

1. Настройте jMeter для работы в качестве реального браузера, настроив (concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Настройте jMeter для генерации пользовательских запросов (путем определения number of users per second, ramp-up time, scheduling, ...)
3. Сконфигурируйте множество клиентов с jMeter для выполнения теста распределенной нагрузки.
4. Обработайте ответ, чтобы определить, правильно ли отвечает сервер во время теста. (Например, ответ assert, чтобы найти в нем текст)

Пожалуйста примите к сведению:

• Начать реальный тест веб-приложения с помощью jMeter легко за считанные минуты. В jMeter есть очень простой инструмент, который записывает ваш тестовый сценарий (известный как HTTP(S) Test Script Recorder).
• jMeter имеет множество плагинов по адресу http://jmeter-plugins.org.
• Пользовательский интерфейс jMeter основан на колебании и внесен хорошие изменения в jMeter 3.2. С другой стороны, учтите, что графический интерфейс JMeter следует использовать только для тестирования и отладки. Не рекомендуется использовать его в режиме графического интерфейса для реального тестирования. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui. Настройте и протестируйте свой сценарий и запустите его в режиме без графического интерфейса.
• Есть много отчетов, показывающих инструменты в jMeter (известный как listeners), но они не предназначены для использования во время тестирования. Вы должны запустить тест и сгенерировать отчеты (файлы .jtl). Затем вы должны использовать эти инструменты для анализа результата. Пожалуйста, посмотрите https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats или https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm.

https://www.blazemeter.com/jmeter содержит очень полезную практическую информацию, которая поможет вам настроить вашу тестовую среду.