Надо сделать и group by time(..)

Без этого да, останется одно значение

Вообщем написал я вопрос и сделал очередную попытку и получилось
магия состоит в том что бы добавить  onEmpty: "keep" в filter

Но там есть прикол что “восстанавливаются” заново все таблицы которые я до этого отфильтровал
пришлось делать и групировку и новый фильтр на поле, а потом ещё сделать сумму значений по колонке…

from(bucket: "gatling")
   |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
   |> filter(
       fn: (r) => r["_measurement"] == "gatling" and
       r["simulation"] == "example" and
       r["request"] == "allRequests" and
       r["status"] == "ok" and
       r._field =="mean" and
       r._value > 35 and
       r._value < 1000,
       onEmpty: "keep"
   )
   
   |> count()
   |> group(columns: ["_time"], mode:"by")
   |> filter(fn: (r) => r["_field"] == "mean")
   |> sum(column: "_value")
   
оставлю, вдруг кому-то пригодится

Буквы Д не хватает ;)

Его надо уметь готовить )))

не смешите мои тапочки

Так в чем трюк-то? Я даже повторил. Вывод - onEmpty: "keep" работает? :)

да, работает

Онлайн стрим

А где про такое узнавать заранее? 🙂

Ага, там не чисто нагрузка, а вообще. Есть интересное, спасибо.

Просто стало интересно, сам еще к Flux только первые подходы делаю. Вот так тоже вроде работает:

from(bucket: "test1")
 |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
 |> filter(fn: (r) => r["_measurement"] == "msrm")
 |> map(fn: (r) => ({ r with _value: if r._value>35 then 1 else 0 }))
 |>sum()

Про минус балансировки между серваками «по количеству коннектов» очень интересную мысль сказал:

Если один из серваков помер (например, отвалился от базы) и на все запросы моментально отвечает http=500 - балансировка «по коннектам» будет скидывать большинство запросов на такой дохлый сервер.

Вместо этого рекомендуется использовать алгоритм pwr2 (если я верно расслышал) - по нему сервера возвращают балансировщику инфо о своей загрузке

Если отвалился от базы разве нагрузка не упадёт?

Серваки/системы с очередями например при не доступности смежных систем оч сильно разгружаются и затем загружаются при доступности и вычитке очереди

🤔

PC не смотрел, под рукой LR\VUGen 2.63.
Только в VUGen 2.5 тыс. папок, 26 тыс. файлов, 1 хром, 1 firefox, 2 node.js, модули на Visual C++, Borland C++, Delphi, Python, Go, Node.JS, C#, Java. Это только что быстро находится.
Скрипты можно писать на C, C++, JS, C#, Java, VBscript, JScript, причем функциональность везде разная.
С и С++ работают через прямые вызовы библиотек, при этом С++ почти не документирован, есть только несколько примеров.
JS работает через Google V8 \ Node.JS.
C# через свою обвязку, может это COM, не смотрел.
VBscript, JScript - через COM\WSH.
У Java своя обвязка, скорее всего обычный JNI, не интересно копать глубже.
С-скрипты выполняются так: (частично это описано в доках) сначала работает препроцессор cpp.exe - это стандартный GNU-тый препроцессор, как они его в коммерческий софт засунули мне непонятно. Он делает из исходников файл pre_cci.c. Его исполняет cci.exe - это фронт (парсер, токенизатор, лексер) от проекта lcc (который тоже в общем-то нельзя использовать в коммерческом софте), к которому прикрутили генератор байт-кода (в проекте lcc его нет). cci.exe на выходе даёт Vugen.ci, в котором байт-код вашего исходника. Потом этот файл с байт-кодом передаётся на вход mdrv.exe, который передаёт его на вход интерпретатору С (vm.dll). Интерпретатор тоже, судя по-всему, местная разработка. Возможно, когда Mercury начала делать LR, еще не было готовых, они и написали свой.
В целом LR напоминает большую кучу из удобрений и палок, связанную синей изолентой. Видно, что когда это перешло к HP, они что-то стали переписывать на Go, но далеко не ушли :)