да по ходу так и должно быть

Привет, вопрос по базисному термину, на который не отыскал детального объяснения в чатике и первой странице гугла:
что из себя представляет VU (virtual user) с точки зрения клиентской и серверной машинки, а также взаимодействия клиент-сервер?
Или же зависит от используемого протокола и/или фреймворка нагрузки?

Вводные данные:
фреймворк/инструмент: k6, http-запросы.

Профили нагрузки:
1) rps:1; vus:1; на энное кол-во минут — в графане вижу, что увеличение кол-ва запросов действительно минимально: + ~1rps. Всё хорошо;
2) rps:1; vus: 1..1000 с разгоном в течение энного кол-ва минут — вижу, что нагрузка увеличилась на ~+100rps в пике, хотя по документации k6 опция "rps" —  "The maximum number of requests to make per second, in total across all VUs" , т.е.  вместо ~+100rps ожидал увидеть нагрузку в ~1rps, по аналогии с опытом №1
— т.е. либо баг k6, что лимит по rps ошибочно не учитывает сумму rps по всем потокам VUs, либо же скрытое законное поведение для VUs, необходимое для существования каждого VU.

Куда копать и что почитать о тонкостях сущности VU?

a ты можешь сделать "pmap -x 35107"?

Сталкивался кто-то с профилированием цпу и памяти haskell? какие инструменты там нормальные есть? * кхе кхе *

Сегодня видел интересный эффект. В конфиге лога одного сервиса параметр http://logback.qos.ch/manual/appenders.html#immediateFlush выставлен в false. Сделано явно (по умолчанию true). И уровень логирования был Debug.

1. На диаграмме работы потоков видно, что пока один поток пишет в лог событие с тестом SQL-запроса, все другие ждут. А в режиме DEBUG все потоки пишут события.
Возможно это особенность логирования именно SQL-запросов, именно той библиотекой, что используется в приложении (doobie). Возможно, особенность отключения  immediateFlush. Но приложение стало работать со скоростью записи в лог одного потока — очень медленным.

2. События попадают в лог неотсортированными по времени. С небольшой погрешностью. Тут думаю точно дело в immediateFlush = false.

Починили 1 отключением DEBUG для SQL. Но вопрос к immediateFlush остался. А ведь возможно, это моя рекомендация когда-то была. Хотел, как лучше

Например FileAppender будет писать на диск и занимать ресурсы, что может приводить в тормозам. То есть он ждет когда запись реально запишется на диск. А SyslogAppender пишет в сислог по udp, тормозов от диска нет, сообщения могут терятся и реордерится.  У меня частенько они оказываются не в правильном порядке без всякого immediateFlush

для винды его нет?

Например FileAppender будет писать на диск и занимать ресурсы, что может приводить в тормозам. То есть он ждет когда запись реально запишется на диск. А SyslogAppender пишет в сислог по udp, тормозов от диска нет, сообщения могут терятся и реордерится.  У меня частенько они оказываются не в правильном порядке без всякого immediateFlush

Можно попробовать писать в файл, обернув FileAppender в AsyncAppender:
https://github.com/qos-ch/logback/blob/master/logback-examples/src/main/resources/chapters/appenders/conf/logback-async.xml
В gatling так делаем, при необходимости писать логи в файл