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

Раньше я использовал Microsoft Web Application Stress Tool и Pylot для стресс-тестирования веб-приложений. Я написал простую домашнюю страницу, сценарий входа и пошаговое руководство по сайту (на сайте электронной торговли добавление нескольких товаров в корзину и оформление заказа).

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

URL-адресом инструментов, которые я использовал, были Microsoft Homer (он же Microsoft Web Application Stress Tool ) и Pylot .

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

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

Ответов (25)

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вам нужен веб-сервис, посетите loader.io .

Резюме:

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

У них также есть 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, который я только что перестал использовать):

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

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

  • Регистратор для записи сценария
  • Использование Akka и Netty, обеспечивающих лучшую производительность по сравнению с моделью Jmeter Threading.
  • 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 - это очень подробные отчеты.

Вот несколько ссылок:
Gatling
Gatling Tutorial

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

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

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

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

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

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

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

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

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

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

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

JMeter looks good from my initial evaluation, I hope to include it in our continuous integration going forward. But, JMeter is complex and non trivial to roll out.

I'd suggest opening another question regarding interpreting the MS stress tool results.

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

Я играл с JMeter. Считалось, что его невозможно протестировать, так это ASP.NET Webforms. Состояние просмотра сломало мои тесты. Я не уверен, почему, но есть пара инструментов, которые неправильно обрабатывают состояние просмотра. Мой текущий проект - 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 вы можете интегрировать «Сеанс производительности», который будет профилировать выполнение кода вашего веб-сайта.

Если вы обслуживаете веб-страницы с сервера 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 ).

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

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