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

Я использовал The Grinder . Это открытый исходный код, довольно простой в использовании и очень настраиваемый. Он основан на 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 GUI» появляется довольно часто).
• Отчетность «из коробки» оставляет желать лучшего, особенно для более крупных тестов. В тесте, о котором я упоминал выше, мне пришлось написать быстрое консольное приложение, чтобы выполнить некоторые преобразования «xml-logfile» в «html». Это было несколько лет назад, поэтому, вероятно, это больше не потребуется.

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

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

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

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

Я бы посоветовал открыть еще один вопрос, касающийся интерпретации результатов стресс-теста MS.

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

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

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

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

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

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

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

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

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

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

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

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

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

оба просты для начала:

ab -c n -t 30 url

siege -b -c n -t 30s url

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

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

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

абы , осада , цзун , httperf , Пробивной , Pylot, запрос лог-анализатор , perftools

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

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

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

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

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

Опять же, отчеты 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 (коммерческая версия с отличной профессиональной поддержкой).

-Frank

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

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

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

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

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

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

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

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

Резюме:

loader.io - это бесплатная служба нагрузочного тестирования, которая позволяет вам стресс-тестировать ваши web-приложения / apis с тысячами одновременных подключений.

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

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

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

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

Jmeter против Grinder

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

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

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

Что лучше:-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// 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
Gatling Tutorial

Я недавно выступил с докладом об этом, вы можете прочитать его здесь:
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 проанализирует и отобразит каждую страницу, выполнит скрипт на стороне клиента. Безголовый браузерный подход облегчает написание тестовых сценариев для поддержки сложного тяжелого Web-приложения AJAX 2.0: навигация по браузеру, щелчок мыши и нажатия клавиш в браузере или ожидание появления элемента в DOM. LoadBooster также поддерживает селеновый HTML-скрипт.

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

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

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

Имейте в виду, что в 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 следует использовать только для тестирования и отладки. Не рекомендуется использовать его в режиме GUI для реального теста. 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 имеет очень хорошую и практическую информацию , чтобы помочь вам настроить тестовую среду.