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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

Здесь другое голосование за JMeter.

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

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

Плюсы:

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

Минусы:

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

ab, siege, tsung, httperf, Trample, Pylot, запрос-журнал-анализатор, perftools

Ответ 6

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

оба запускаются просто:

ab -c n -t 30 url

siege -b -c n -t 30s url

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

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

Ответ 7

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

Резюме:

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

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

Ответ 8

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

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

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

Jmeter vs Grinder

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

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

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

Что лучше: -

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

Я сказал бы, что начну с Jmeter, поскольку этот инструмент имеет огромное количество результатов, и в Интернете есть много примеров и руководств по использованию этого инструмента. Если и когда вы придете к "дорожному блоку", это то, что вы не можете "легко" сделать с Jmeter, а затем взгляните на Grinder. Хорошая новость заключается в том, что оба этих инструментария имеют одно и то же требование Java, а решение "mix and match" не может быть и речи.

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

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

Из опыта около 25 экземпляров "безгласных браузеров" можно выполнить из небольшого экземпляра Amazon M1.

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

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

Ответ 9

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

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

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

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

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

Вот несколько ссылок:
Gatling
Учебник Gatling

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

Ответ 10

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

Ответ 11

Кроме того, существует удивительный open-source pure-python распределенный и масштабируемый locust framework, который использует greenlets. Это отлично подходит для имитации огромного количества одновременных пользователей.

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

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

Он с открытым исходным кодом и свободен.

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

Ответ 18

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

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

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

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

Ответ 19

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

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

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

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

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

Ответ 20

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

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

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

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

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

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

Ответ 21

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

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

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

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

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

-Frank

Ответ 22

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

Ответ 23

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

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

Ответ 24

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

Ответ 26

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

Ответ 27

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

Ответ 28

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

  • Легко script взаимодействие с пользователем
  • отчет очевиден.
  • может контролировать загрузку сервера.

Ответ 29

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

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

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

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

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

Ответ 30

Я проголосовал за jMeter, и я хочу добавить некоторые цитаты в ответ @PeterBernier.

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

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

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

  • Настройте jMeter как действительный браузер, настроив (concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support,...)
  • Настроить jMeter для генерации пользовательских запросов (путем определения number of users per second, ramp-up time, scheduling,...)
  • Настройте множество клиентов с jMeter на них, чтобы выполнить тест распределенной нагрузки.
  • Ответ процесса, чтобы определить, правильно ли сервер отвечает в ходе теста. (Например, 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. Настройте и протестируйте свой сценарий и запустите его в режиме без 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 имеет очень хорошую и практичную информацию, которая поможет вам настроить тестовую среду.