Ну то есть управление условным коннекшнпуллом а не тредпуллом

Ох. Получается это вообще не thread group, а «virtual user group»!

это, кстати, интересное наблюдение

о отлично, буду иметь в виду)

Прямо сейчас (в openmodel) это thread pool, и каждый «поток» выполняет действия один раз и выходит.
Но и thread(…) в dsl сейчас нет.

Так-то мне хотелось добавить ограничитель
1) на одновременное количество активных потоков — это, наверное, threads (или concurrency)
2) на количество активных сессий — это, наверное, virtual users

И тут я склоняюсь к тому, что
№1  — ограничитель на concurrency — должен быть на уровне openmodel — оно должно понимать когда *можно* запускать новые потоки, а когда упёрлись в ограничение.

№2 — похоже, нужно делать на уровне testplan’а. Т.е. это либо какой-то элемент «reconnect» или «virtual user pool» или ещё что-то. Иными словами, текущую галочку «same user on each iteration», наверное, нужно превратить в дочерний элемент, который со своей частотой будет сбрасывать куки, переподключаться и т.п.

пора жметр переписывать

по поводу галочки ее по хорошему надо в test control action воткнуть, оно вполне логично

Ну вот может threads по другому как-то назвать. Хотя все привыкли конечно что в jmeter thread=user. А юзер конечно тоже непонятно что. Ну вообще в джеметр реализовано так что юзер некоторая выполняемая  последовательно в 1 потоке цепочка действий,

да нужно поделить эти штуки на коннекты и итерации, вся путаница уйдет

имхо конечно

Было бы конечно круто об этих тредах и конектах не знать вообще указать длительность, рейт, и сколько там соединений/сессий использовать. А планировщик какой-то это сам там пуллами рулил и не блокировался где попало и не создавал по 500милионнов потоков. Я помню вы Владимир хотели ещё чтобы каждый семплер в корутине выполнялся, это тоже будет в новой тредгруппе?

ну это не совсем правильно. в конечном счёте системе под нагрузкой все равно сколько тредов или других абстракций, но коннект не абстрактен - для ряда случаев это может влиять на нагрузку. сейчас реально провести аналогию с коннектом опираясь на треды и их конфигурацию, а вот если это будут просто параметры планировщика - не уверен

Ну так нужно задавать планировщику сколько соединений открывать. Некоторый такой конекшн пулл. А как он будет использоваться потоками это дело планировщика потоков. Вот когда у вас поток хватает соединение и пока всю цепочку запросов не прокрутит - не освободит ни соединение ни поток. Это не оптимальное использование ресурсов из-за этого у всех оверфлов ероры и  тесты падают. И вообще самая часто встречаемая проблема у новичков с джеметром, это типа мне надо 100500 пользователей я написал 100500 потоков-пользоватей и у меня всё упало. А потом они узнают что это оказывается не пользовали а джвм-треды, которых 100500 создавать не очень хорошая идея и дальше все вот эти штуки с особенностями джеметра и джвм. Я считаю что нужно эту привязку пользовалей к потокам нужно убирать. Сделать нечто абстрактное, например виртуальных пользователей, которые собой представляют последовательность некоторых действий связанную с ресурсами которые им нужны для выполнения своих действий важных для серверной стороны(например это соединение) выполнять эти действия на небольших тредпулах 8-10 потоков, в неблокирующем режиме так сказать. Ну в случае котлина например можно засунуть все семлеры в корутины и вам вообще не надо ничего про потоки знать, там планировщик потоков сам разрулит как чего блокировать и запускать

в java тоже есть корутины)
а так - я почти про то же. пуллер коннектов вместо тредов

Коннект это ресурс, а тред это незнамо шо

Ну это про project Loom? Его же ещё вроде не влили в jvm? Я не хочу разводить холивары, но в том же гатлинге и к6 например вообще про потоки, тредпуллы знать не надо пишите рейт, пользоватей виртуальных и всякие абстрактные вещи. Однако джеметр считают более дружественным к пользователю инструментом, потому что в нём можно в гуи сценарии накликать, а не кнопками на клавиатуре набирать. Однако чтобы успешно пользоваться джеметром, нужны более глубокие знания о платформе на которой он исполняется. И здесь уже как-то не очень дружественно получается.

а чем будет разница между 10 юзерами в жметер, 10 в гатлинг и 10 в к6?)

В жеметре это 10 потоков в джвм, ну который 1 к 1 мапятся на треды ОС. В гатлинге это некоторые такие акторы, которые легковесные которых можно миллионы создавать, и которые выполняет планировщик на каком-то тредпулле, возможно даже не на одном, потому что там есть по крайней мере 2 пула потоков, один для вычислительной нагрузки(типа математику какую-то посчитать) другой для всякого там блокирующего ввода-вывода. В к6 скорее всего го-рутины, которые тоже на планировщике потоков гошном исполняются, которые мапит на треды ОС не 1 к 1

Я сам не видел, но думаю, что в го тоже что-то вроде 2 пуллов, один для вычислений типа джавового ForkJoinPool, а другой для блокирующего ввода-вывода типа FixedThreadPool или CashedThreadPool в java

понял, да так и думал. ну мне не кажется это прямым минусом, со стороны прозрачности действий всё очень четко. тебе надо N потоков - будет четко N потоков, они должны делать X коннектов - чуть сложнее, но тоже пожалуйста делай