Рубрика «jmeter»

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

В этой статье мы рассмотрим NBomber как легкую для освоения альтернативу JMeter, а также постараемся ответить на вопрос "Почему я должен проводить нагрузочное тестирование именно с NBomber ?".

Читать полностью »

Мы задумались о построении инфраструктуры больших нагрузочных тестов год назад, когда достигли отметки в 12K онлайн-пользователей, работающих в нашем сервисе одновременно. За 3 месяца мы сделали первую версию теста, которая показала лимиты сервиса.

Ирония судьбы в том, что одновременно с запуском теста мы достигли лимитов на проде, в результате чего сервис упал на 2 часа. Это дополнительно стимулировало нас начать двигаться от проведения тестов от случая к случаю к созданию эффективной нагрузочной инфраструктуры. Под инфраструктурой я подразумеваю все инструменты для работы с нагрузкой: инструменты для запуска и автозапуска, кластер для подачи нагрузки, кластер, аналогичный проду, сервисы для сбора метрик и для подготовки отчётов, код для управления всем этим и сервисы для масштабирования.

Достоверный нагрузочный тест с учётом непредвиденных нюансов - 1
Читать полностью »

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

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

Очереди и JMeter: обмен с Publisher и Subscriber - 1
Читать полностью »

Боевые стрельбы в ночи, или Почему нагружать прод — не страшно - 1
«А если ты не выстрелишь, то испорчусь я»

Ещё недавно считалось, сервис должен просто работать. Нарисовали, заверстали, написали скрипты — вроде всё ок, можно катить на прод.

Но конкуренты не дремлют, поэтому начинается гонка не только за новыми функциями, но и за скоростью работы. Любое зависание приложения или долгий ответ сервера (не говоря уже про всплывающие 500-е ошибки) портят впечатление от сервиса и вынуждают пользователя уходить куда-то ещё. Наверняка, каждый сталкивался с ситуациями, когда вместо покупки билета на самолет, поезд или концерт на экране отображалось «Internal server error», и вы в ярости хотели разбить монитор.

Я — Виктор Бодров, работаю в Яндекс.Деньгах в команде исследований производительности и хочу рассказать о том, чем полезно изучать производительность прямо на продакшене.

Читать полностью »

Привет!

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

На этот раз расскажу о своем опыте примирения JMeter и IBM MQ для счастливого тестирования приложений на IBM WAS. Сталкивался с такой задачей, легко она не поддавалась. Хочу помочь сэкономить время всем заинтересованным.

IBM MQ и JMeter: Первый контакт - 1

Читать полностью »

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

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

Разработка нагрузочных скриптов для браузерных-мобильных игр. Часть 1 - 1
Читать полностью »

11 февраля состоялся релиз новой мажорной версии 4.0 Apache JMeter. Поскольку мы используем этот инструмент для нагрузочного тестирования на многих проектах, мы не могли оставить данное событие без внимания.

Предыдущий мажорный релиз (версия 3.0) был выпущен чуть меньше двух лет назад (для сравнения, версия 2.0 вышла аж в 2004-м!). Также за последние 2 года было выпущено несколько минорных релизов (версии 3.1-3.3). Это показывает нам, как JMeter развивается, чтобы шагать в ногу с новыми технологиями и соответствовать нуждам разработчиков.

Похоже, что в новой версии JMeter акцент прежде всего сделан на улучшении пользовательского интерфейса (UX). Процесс навигации и создания тестов стал проще, элементы — дружественней и удобней, а система оповещения пользователя о проблемах с тестами переработана.

JMeter 4.0. Что нового? - 1

Под катом самые важные изменения в JMeter 4.0, о которых вам нужно знать.
Читать полностью »

Привет!

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

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

Сам процесс нагрузочного тестирования в своём сознании я делю на несколько этапов:

Нагрузочное тестирование, история автоматизации процесса - 1
Читать полностью »

Пару слов для начала

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

  1. Apache JMeter – инструмент для нагрузочного тестирования, который способен проводить тесты для JDBC-соединений, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP из коробки и еще множество других протоколов и решений, используя различные плагины.
  2. Yandex.Tank – это облачный инструмент для нагрузочного тестирования, использует различные генераторы нагрузки, в том числе и JMeter.
  3. Yandex.OverLoad – сервис для удобного мониторинга и анализа серверов под нагрузкой.

Читать полностью »

image
Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:

Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  452793 requests in 10.03s, 58.30MB read
Requests/sec:  45133.28
Transfer/sec:      5.81MB

elixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  184703 requests in 10.02s, 28.57MB read
Requests/sec:  18441.79
Transfer/sec:      2.85MB

Как жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js