Если с InfluxDB проблемы из-за большой базы данных, то можно поступить так:

1. Сделать отдельную новую базу данных.
2. В ней сделать retention policy с временем жизни метрик 1 месяц. Только для оперативных метрик из JMeter. Такая база данных будет очень маленькой. Influxdb всю ее будет в памяти хранить. И работать быстро.
https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#create-retention-policies-with-create-retention-policy

CREATE RETENTION POLICY "one_month_only" ON "jmeter_database" DURATION 31d REPLICATION 1 DEFAULT

3. А чтобы хранить историю отчетов использовать Grafana Snapshot-ы отчетов.

Так метрики будут сами удаляться из InfluxDB через месяц. Сравнивать два запуска средствами InfluxDB не получится уже, метрик не будет, останется только картинка - Grafana Snapshot. Но если сравнивать ничего не надо, то экономичный и простой вариант

Всем привет, кто может подсказать, нужны ли стандартные header под каждым запросом или нет? Мне кажется они нагружают процессор

А так же не могу разобраться с timers, сколько их нужно использовать, у меня несколько sample controller и какие? constant timer достаточно добавить в thread group или еще нужен дополнительный типо uniform throughout timer. На выполнение одного сценария уходит примерно 20000 мс, но есть некоторые запросы, которые сами по себе долго выполняются, под ними нужен таймер дополнительный?

CREATE RETENTION POLICY "one_month_only" ON "jmeter_database" DURATION 31d REPLICATION 1 DEFAULT

такс, это всё очень странно)
retention policy по дефолту стоит 168 часов - это лучше чем месяц так как данных внутри немного, это работает быстрее. с дефолтными настройками ничего не разрастается. у меня 1 шард с тестом весит максимум 750 Мб, а чаще это до 100 Мб.
Итого у меня база 10 Гб за два года, с тестированием на постоянной основе 3-5 проектов еженедельно.
Для сравнения телеграф метрики с 8 машин за те же два года нагенерили 3,5 Гб, а там они агрегированные.
По дефолту в инфлюксе стоит еще и шардирование, оно происходит чаще чем сброс данных по retention policy поэтому все данные хранятся в меташардах, и у тебя всегда есть к ним доступ. размера они тоже небольшого - следовательно в рамках недели всё работает почти мгновенно, когда работаешь с более давними временными интервала - всё работает чуть медленнее и нет проблем

агрегация не нужна при записи в БД, нужно правильно оттуда взять данные делая группировку GROUP BY time - например, тогда будет происходить автоаггрегация - это дешевая операция

я глубоко не изучал тему, но при определенных обстоятельствах и настройках всё может быть не очень хорошо, к примеру отрисовка дашборда составляла ~3-5 минут

Добрый день. Подскажите, пожалуйста, чем удобнее пользоваться для параметризации конфигурации подключения к БД.
Так как нельзя  использовать в JDBC Connection Configuration параметры, считанные из CSV DataSet Config ( Jmeter считывает параметры из csv после подключения к БД) , а передача при запуске в командной строке URL, User и pass для нескольких баз данных громоздко, возможно есть более удобное решение?

дефолтные настройки - ничего не менял)

я к тому что проблема в дашбордах)

у меня с этой же БД отрисовка составляла и 10 мин

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

для jmeter несложно их подставлять

понял, спасибо

вам нужно убрать все лишние таймеры и добавить 1 - который бы котролировал интенсивность запросов например constant throughput timer или throughput shaping timer, эти таймеры будут сами ставить задержки после запросов, чтобы достичь целеевого значения рпс

как раз то, что нужно, спасибо за помощь :)

а какую логику надо реализовать? каждый юзер заходит под новым логином

?

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

можно в файле user.properties задать нужные вам параметры
например
myprop=qwerty
и дальше в Jmeter использовать
${__P(myprop,)}