Да, тоже не смог ничего пока придумать. Если вставить очень много данных, то начинается переиндексация. Она может сьесть много памяти.

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

Но ручаться не буду, что это помогает всегда

  # The type of shard index to use for new shards.  The default is an in-memory index that is
  # recreated at startup.  A value of "tsi1" will use a disk based index that supports higher
  # cardinality datasets.
  # index-version = "inmem"

Поменял на tsi1.

Ещё сделал в базах retention policy

month - 30 дней, размер shard-ы 1 день
year - 365 дней, размер shard-ы 10 дней

Так малые индексы получаются. Пока метрики пишутся в пределах текущего дня, в памяти видит только индекс за 1 день. Когда исторические запросы выполняются - индекс читается с диска

Это пока попытка как-то решить задачу, научным методом "тыка"

[vv

хмм
надо учесть, спасибо

Доброй ночи.

Кто-нибудь сталкивался с такой темой, что Module Controller в JMeter’е полностью отрабатывает только первый раз, а при последующих обращениях игнорирует некоторые запросы?

Ситуация: в тред-группе 4 идентичных модуль-контроллера, ссылающихся на один и тот же симпл-контроллер в test-fragments. В этом симпле лежит 8 запросов – 1 пост и 7 гетов. При первом обращении к контроллеру, выполняются все 8 запросов, при последующих – только один пост.
Есть еще 4 других модуль-контроллера, ссылающихся на другой симпл-контроллер в test-fragments, содержащий 2 гета и 1 пост. При первом обращении отрабатывает полностью, при последующих – теряет один из гет-запросов…

Кэшировние

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

Варианты решения:
1) если у тебя обычная тред-группа и свежий жметер - в свойствах группы сними галочку «same user each iteration»

(Как-то так, точно не помню)

Если у тебя ultimate thread group или что-то такое - https://www.blazemeter.com/blog/using-http-cache-manager

Хмм
Судя по статье, same user on each iteration действует только на куки.
Но я бы проверил.

https://www.blazemeter.com/blog/introducing-jmeter-5.2

Same User on each iteration имеет действие: не закрывать соединение после завершения итерации

https://bz.apache.org/bugzilla/show_bug.cgi?id=62861

Чтобы JMeter быстрее работал. Теперь он работает быстро по умолчанию. Пул соединений используется на постоянной основе, не открывается и не закрывается. TCP Time Wait Connection не растёт

Это если используешь дефолтные группы

А мы в основном гоняем тесты на макс.перф, со ступенчатой нагрузкой

И там такой галочки нет :((

Дефолтные группы юзаем только для отладки.

Даже если тест стабильности (ровная нагрузка часов на 12) - тоже UTG.
Потому что у нас автоматизация
В user defined variable вводим параметры теста:
- разгон за 10 минут
- бейзлайн держать 20 минут на уровне 100% профиля,
- далее ступеньки + 20%
- ступеньки разгоняются за 5 минут и держатся 15

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

В результате что бы подать нагрузку на другом уровне нам достаточно поменять 1-2 цифры.

Это проще, чем перепиливать всё на дефолтные тред группы

Тогда можно в property явно выставить

httpclient.reset_state_on_thread_group_iteration=false

Так и сделал, спасибо твоему докладу :)

Иногда   post запросы кэшируются, крайне редко, но находит применение.

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

https://hsto.org/webt/dd/8x/1h/dd8x1hbjpqymimae5djldsaikvq.png

Что выяснил. Оно гораздо точнее и компактнее, чем перцентили, при долговременном хранении и усреднении.

Сейчас, чтобы хранить метрики и их разброс в InfluxDB сохраняю 10 точек: среднее + (max, 99%, 95%, 75%, 50%, 25%, min). И чтобы отображать пернцентили на графиках применял такой способ агрегации:

* percentile("99%", 99) ... GROUP BY time($granularity) - устердненное значение 99%, как перцентиль от перцентиля
* percentile("95%", 95) ... GROUP BY time($granularity) - устердненное значение 95%, как перцентиль от перцентиля
* ...

Выглядит логично. Но математически это неверно. 99% от серии 99% не будет соответствовать 99% по всем исходным значениями серии.
Посчитал получаемую погрешность. Она получается 20-60%.

А если использовать стандартное отклонение. И усреднять его, просто усреднять. То средняя погрешность 13%. Стабильная, небольшая. Без разбросов.

А визуально использование в отображении mean плюс/минус stddev даёт сопоставимый с перцентилями результат.

Плюс, вместо 10 точек, можно хранить две: среднее и отклонение. Или 4: среднее, отклонение, минимум, максимум. Это экономия размера базы данных - залог скорости работы.

И если вы не использовали раньше отклонение. Стоит обратить на него внимание

ты же про дисперсию?

stddev - квадратный корень из дисперсии

В Grafana это выглядит так: https://hsto.org/webt/vj/jo/dk/vjjodk7bow6wsizgnf0u9efw7yy.png
В математике так: Среднеквадратическое отклонение