и дальше бы уже срезал (?), если на это есть объективные причины по костам

Привет. Для теста gateway можно мало gateway, много payment. И повышать их количество, смотреть, как они мастаьируются. Могут не масштабироваться вообще. Или упираться в соединения, диск, ... Даже в мониторинг могут упираться или защитные механизмы.

Для теста back (payment) нужно gateway с запасом и тоже самое сделать с payment. Проверить мастабируются ли он. И как: увеличением контейнеров или потоков внутри контейнера.

А для мастабирования у заказчика нужны RPS. Профиль нагрузки. Мониторинг. Большая работа

я просто в setUp кладу адрес проекта в проперти и все нужные файлы держу в той же директории, что и проект

import org.apache.jmeter.services.FileServer;

props.put("testPlanFileDir", FileServer.getFileServer().getBaseDir().replaceAll("\\\\", "/"));

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

моя первая задача была просто найти текущий baseline. посмотреть совпадет ли он с критериями (response time, concurrent threads) от продактов. критерии были выбраны на основании прогноза  по прибавке пользователей к концу года. мы взяли тестпрофиль 30параллельных тредов 30 warmup, 30 time и каждое API затестили. много FAIL результатов. начали обсуждать и тут разрабы говорят а пчму вы тестите с 1 контейнером. у нас в рекомендованной конфигурации их 2 для payment и ряда других >< типа с 2мя скорее всего PASSED будет.

у нас пока не было задачи тестить маштабируемость.  много API работают медленно из-за кода и сначала это надо улучшить.

а дальше будет bottleneck в базе. это видно на быстрых апишках. read/write Disk медленных и CPU Basic usage в MySQL забивается очередью из queries. когда добавим для быстрой апишки еще один контейнер, то БД будет тупить.

так.так. до меня начинает доходить.
1) для baseline верно использовать 1 контейнер, кроме gateway?
2) если увеличивать кол-во конейгеров, то это уже тестирование маштабируемости? даже если это изначальная дефолтная конфигурация системы?

Был опыт тестирования масштабирования. Где сервис не масштабировался. Хотя должен был. Поэтому да, тестировать мастабирование надо. И теперь без теста не говорю, что 2 сервиса будет быстрее одного

И так не выяснили почему не масштабируется. Он просто быстрый. На какое-то время его хватит

интересная фигня хД

import org.apache.jmeter.services.FileServer;

props.put("testPlanFileDir", FileServer.getFileServer().getBaseDir().replaceAll("\\\\", "/"));

Кстати, есть плагин PropertyFileReader
Читает проперти из файла

Всем привет.

Я неофит и я не из опсов - не тестер, не кодер.

https://k6.io/blog/comparing-best-open-source-load-testing-tools взял за основу выбора инструмента. Плюс всё, что выдал стандартный получасовой ресёрч по стековерфлоу.

Собстна, вопрос простой - JMeter vs Tsung. Каков мой оптимальный выбор на старт при учёте того, что энтрипоинт от девелоперов - har-файл и всё? Пока что всё, на что ориентируюсь при выборе - Tsung много производительнее (спасибо Эрлангу за это). Никсы - не проблема (моя специализация), XML для описания - тоже вроде как не проблема (есть трансформ xml2jmx, есть трансформ jmx2tsung). Из потенциально нужного помимо просто http - ws.

k6)

есть инфа (возможно, неактуальная), что tsung опережает jmeter по метрике req/sec. Также jmeter кушает много больше ресурсов на один req.
как ведёт себя k6 сравнительно с этими двумя? есть где-то какие-то бенчи?

какой уровень нагрузки предполагается?

ну... справедливый вопрос.
Наверное, стоит попробовать k6 и больше ничего не выбирать. Спасибо

Привет, интересная статья.

Уделил когда-то время понимаю того, как люди сравнивают производительность инструментов. И почему в тестах на сравнение RPS JMeter проигрывает.


Вот ценный комментарий из документации к Gatling:
https://gatling.io/docs/current/http/http_protocol#connection-sharing

In Gatling 1, connections are shared amongst users until 1.5 version. This behavior does not match real browsers, and doesn’t support SSL session tracking.

In Gatling 2, the default behavior is that every user has his own connection pool. This can be tuned with the .shareConnections param.

Сейчас, в тактуальной версии Gatling, он использует более "реальный" вариант управления подключениями, чем раньше. Такой же вариант и в JMeter. Но не в wrk, ab, ... И поэтому они быстрее, кажется, если писать вот такие простые скрипты, как в статье (Here is what a very simple Gatling script may look like: ...).

Но если включить ShareConnection в Gatling или
сделать

httpclient.reset_state_on_thread_group_iteration=false

в JMeter, то и тут, с 1 пользователя можно получить несколько тысяч RPS.
Это к тому, что любая нагрузка в любом инструменте возможна. И в Loсust тоже можно тысячи RPS подавать, если захотеть.

А далее уже стоит сравнивать - какие отчёты в инструменте.
И как гибко можно задавать профиль нагрузки.

1. Работа с нужным протоколом. И удобство работы.  Корреляция запросов.
2. Отчёты.
3. Профиль нагрузки.
4. Документация, ... просто личные предпочтения.

А RPS не так важен для начального выбора.

И в  JMeter vs Tsung выбрал бы JMeter. Из-за удобства отладки. Что пригодится при работе с ws.

In Gatling 1, connections are shared amongst users until 1.5 version. This behavior does not match real browsers, and doesn’t support SSL session tracking.

In Gatling 2, the default behavior is that every user has his own connection pool. This can be tuned with the .shareConnections param.

httpclient.reset_state_on_thread_group_iteration=false

Спасибо за мнение.
Пожалуй, стартану с k6 из-за удобства в первую очередь.

Коллеги добрый день! Подскажите плиз кто сталкивался с jdbcFeeder в гатлинге? Возникает проблема при старте теста и ошибка java.sql.SQLException: No suitable driver found for jdbc:oracle:thin:@${host}:1521:${scheme}

Оф документация не очень подробна

Only JDBC4 drivers are supported, so that they automatically registers to the DriverManager.