Да, он

а, типа ручками json -запрос править?

У нас так кто то делал точно ж

инфлакс, да

Я как-то видел такой дашборд, но сейчас под рукой нету. Там делается самими запросами к influxDB. Хотя вот гугл еще такую штуку предлагает https://github.com/maxsivanov/influxdb-timeshift-proxy

хмм. Ладно, пока попробую в JSON вкатать переменную с сдвигом.

Люди используют некий influxdb-timeshift-proxy, чтобы передавать из grafana значение сдвига в Influxdb

Сделать два графика, друг под другом

Так и скажи: "используй своё воображение, поросёнок пётр"

- Как вас представить?

- Представьте меня на белом коне!

Сдвиг на 10 минут в прошлое. Можно сравнивать, было, стало. Техническая проблема - передать точный размер сдвига в Grafana. Указав его в URL между текущим тестом и предыдущим. Но ведь это можно сделать

Не знаю на сколько законно, но как раз недавно смотрел видос с конфы где чувак делал шаблон для подобного, но там тоже influx-timeshift в готовой обёртке, проект:
https://github.com/serputko/performance-testing-framework

Я стырила много хорошего с этого проекта. Насколько я знаю, Антон ссылку на этот проект всем давал, кто его мастер-класс посещал (я не посещала), так что думаю - законно ))))))))

Я не про распространение его ссылки(репа же открытая), а про скидывание её сюда)

Коллеги, привет, подскажите плз, у меня в заглушках реализуются задержки на activeMQ через шедулер, возникла проблема что его производительности не хватает, и время отклика растет, шедулер в свою очередь использует кахудб на диске, можно ли шедулер как то в опреративной памяти использовать?

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

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

А ее производительность контролируется интенсивностью работы планировщика.

Если да, то узкое место может быть и не в базе. А в активном запуске процессов.

Надо замониторить.

И если так. То можно перейти от процессов к потокам. В качестве планировщика использовать Apache.JMeter, а работу запускать из Java Sampler или JSR 223 Sampler.

https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/ActiveMQ_Tuning_Guide/files/PersTuning-KahaDB.html

Вот тут пишут, что если выставить
enableJournalDiskSyncs
в false, и увеличить размер журнала, то БД ускорится -- будет в ОЗУ

Задержка != ограничение производительности