Comments 24
JMeter
удобный GUI
Серьезно?
Если что, мне пишите.
Про удобный GUI у JMeter, вы конечно сильно загнули.
Давайте представим, что мы с вами написали некоторый сервис — для определённости скажем, что веб-сервис, но это не столь важно.
Но ведь это очень важно. Разве большинство из упомянутых вами решений умеют нагружать какие-либо кастомные протоколы? Да хоть что-то отличное от HTTP?
У Gatling также отсутствует возможность делать распределённое тестирование, что ограничивает возможные области применения.
github.com/Pravoru/gatling-remote-sbt — удалённо-распределённый запуск
github.com/Pravoru/gatling-junitrunner — дебаг в ide. Ибо крайне надоедает дебажить через вывод в консоль.
Представим, что мы с вами написали некий сервис — теперь нужно понять, какую нагрузку он выдержит.
А разве таков должен быть порядок, не наоборот ли? Не сперва ли нужно решить под какими нагрузками планируется работа сервиса? И отталкиваясь от этого подбирать и железо и ПО и прочее.
А то по вашему получается, что, если вдруг заданную нагрузку этот сервис не выдерживает, то что делать с ним? Переписывать? И так каждый раз после очередных нагрузочных тестов?
Спасибо за статью. Особенно за Gatling, полагаю, изучить его и Scala интереснее, чем написать хороший плагин для HTTP/2 к JMeter. А там уж можно взяться и за хороший плагин.
Есть ещё Visual Studio Enterprise, где можно писать нагрузочные тесты. Удобно использовать для тестирования тех же веб-сервисов, если веб-сервис является WCF-сервисом сделанным с помощью net.tcp (SOAP/MSBin1 через TCP) или SOAP/MSBin1 через HTTP(S). LoadRunner для такого проекта получится дороговатым. Можно использовать JMeter, для такого проекта, если постараться, JMeter может нагружать всё благодаря Java и магии. А если надо нагрузить WCF-сервис быстро и легко, без переходников и с удобной отладкой, то Visual Studio — разумный выбор.
Если сервис использует SOAP/XML через HTTP(S), то, конечно, можно использовать множество инструментов, все те, что поддерживают HTTP 1.1, GET и POST-запросы уже сгодятся. Тут уже можно попробовать забыть, что это WCF.
У Visual Studio Enterprise есть и облачная версия для нагрузки. Предполагаю, что если код теста использует какое-то специфичное окружение, например, кроптовайдеры, то воспользоваться облаком не получится. А для простых тестов, где надо много IP-адресов самое оно.
У HP LoadRunner есть вариант с частным облаком — HP Performance Center. Скоро он станет похож на Яндекс.Танк, сможет использовать JMeter в качестве генератора. В ноябре, на сколько помню это случится. У тех, кто использует альфа-версии это уже есть.
Можно вопрос. Какой из инструментов самый забагованный?
Просто видел баги во многих инструментах. Из недавнего. В HP Perfrmance Center можно схватить утечку памяти легко на длительных тестах HTTP с большой интенсивностью. В HP LoadRunner для нового скриптового языка JavaScript пока не реализована поддержка UTF-8 и кириллицы, не получится красиво обрабатывать JSON и делать прочие трюки javaScript для русскоязычных сайтов. В Apache.JMeter и комбинации работы его плагинов россыпи багов, не очень критичных, но они есть — знаю про них много, так как работаю с ним часто. В Visual Studio не видно багов, там ломаться особо нечему, она как Gatling для C#, но там есть недостаток — ресурсов требует много для создания нагрузки, может понадобится несколько нагрузочных агентов там, где бы другие инструменты отстрелялись в одиночку.
Ещё вспомнил ZebraTester. Друг его использует в работе. Рассказывал, что ZebraTester используется в AOL или в какой-то такой компании, для тестов контентых ресурсов под большой распределённой нагрузкой. Удобен для HitBased-тестирования веб-проектов по HTTP(S), где нагрузку нужно подавать из облака распределёно. Это как простой BlazeMeter.
И отдельная тема в нагрузочном тестировании, когда нагрузку нужно создать не очень большую, или когда железа много — использование автотестов (модульных или функциональных) для создания нагрузки. Так очень многие делают. Например, тест на веб-приложение, с использованием Selenium WebDriver и PhantomJS, а Cucumber и его синтаксис для задания сценария вообще тренд. Или тест на веб-сервис, где модульные тесты не используют заглушки и моки, а работают с полноценным сервисом и грузят его как клиенты. Люди фреймворки пишут, для логирования, для таймингов, для большей параллельности. Это целый мир со своими бонусами и ограничениями.
Здравствуйте. Готов помочь с Apache.JMeter.
Если речь о хитах в секунду, то 1к запросов в секунду — прекрасный показатель.
На недавнем тесте мой профиль был 500 запросов в секунду с двух Apache.JMeter в сумме. Но моей целью не было найти технологический предел JMeter по подаче нагрузки. И каждый третий запрос был тяжёлым, как минимум один PostProcessor и Assertion, а где-то и несколько.
Когда упираюсь в некий предел нагрузочной станции, то использую две-три-четыре станции. Это нормально. Если нужно увеличить хиты в секунду, в hit-based тесте, то можно использовать ab из httpd-tools (не работает с самоподписанными сертификатами, но сгодится для http или корректных сертификатов) или аналоги. Если нужна логика работы запросов с завязкой на тестовые данные и связанность операций, то нужен JMeter. Цена добавления логики — снижение максимального количества хитов в секунду.
В любом случае, напишите. Буду рад помочь.
Обзор инструментария для нагрузочного и перформанс-тестирования