я выбирал исходя из параметризации на лету, минимума кода и производительности. глянул почти все популярное, но пропустил разработку от Андрея Похилько из блейзметра https://up9.com/open-source-microservice-mocking-introducing-mockintosh

оно выглядит очень круто

прикольно, я попробую все равно)

Тесты производительности MockServer показали, что самый производительный метод - Java Callback

Это когда ответ на запрос формируется Java-кодом. Другие способы, генерирование ответа по описанию, менее производительные выходили.
https://t.me/qa_load/55269 тут ссылаюсь на Java-callback как раз

А где то есть тесты разных mock серверов? Например на текущем проекте wiremock, интересно как он например

А как ты сделаешь так, что приложение, условно - сервис на spring отправит в заголовке запроса к другому сервису какой-то твой заголовок?
Сделать так, что ты сам из JMeter изредка шлешь корректирующие настройки куда проще.

вообще странно видеть реализацию через thread.sleep.  я делал через executer thread pool. Они сами по мере освобождения принимали новые задачи, без блокировок потока

Вы паузу просили

присоединяюськ вопросу, тут же в чате писали, что он медленный и возражали, что это не так😄

все верно, паузу без блокировки потока который принял запрос в обработку

треад слип же может положить моку или в ограничения по потокам ОС упереться

Такое тоже есть. Но оно как-раз не в Java Callback, а во всех других случаях

аа понял

Может настраиваться даже через HTTP API

Есть методы отправить на специальную ручку запрос с JSON в котором будет и что обрабатывать и как отвечать и с какой паузой. Будет ли там блокировка потока при реализации не знаю

Утверждать, что там именно будет неблокирующее все, не стану.
Но возможно оно там неблокирующее.
Но сам парсинг этого JSON правила выполняется на каждый запрос - это замедляет заглушку на высоких нагрузках (выше 10 RPS)

Спящие потоки не так уж и дороги. Практика показала, что даже если из 200-500, это терпимо

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

У меня тоже вопрос есть, но другой. По PostgreSQL и колонке QueryID,

Есть такая цитата из документации
https://postgrespro.ru/docs/postgrespro/9.5/pgstatstatements

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

(часть 2 цитаты)
Так как значение хеша queryid вычисляется по представлениям запроса на стадии после разбора, возможна и обратная ситуация: запросы с одинаковым текстом могут оказаться в разных записях, если они получили различные представления по разным причинам, например, из-за изменения search_path.

Вот сделать так, чтобы один запрос с одинаковым текстом разделился на две разные queryid в статистике смог запросто сделать. А вот сделать часть 1 никак не получается. Ни как не могу придумать такой запрос, запросы, чтобы тексты были разные, но семантически равнозначны.