поэтому я бы по возможности убрал оттуда всю или почти всю логику

Да, мы вчера это обсуждали))) что сервер который много генерит скорее всего сдохнет быстрее

Так, с этим разобралась. Это ещё не все глупые вопросы 🤣

Конкретно тут не вопрос глупый, а задание

Всем привет. Кто-нибудь знает, как с помощью wiremock настроить времена ответа таким образом, чтобы запросы отвечали с задержкой в процентилях?

Спасибо, сделал так, всё заработало )

Хорошо) но лучше, как советовали выше, поставить wsl2 и там уже докер установить, проблем будет чуть меньше чем с toolbox:
https://docs.microsoft.com/en-us/windows/wsl/install-win10

ок, нужно будет разобраться только что это и как это )

Вы тестируете трёхзвенную систему:
Клиенты => сервер приложений => БД
Нагрузка увеличивается в ходе всего теста, а производительность – только в первую половину теста.
При изучении логов сервера приложений вы обнаруживаете, что приложение ожидает работу компонента, ответственного за взаимодействие с БД.
При этом на сервере БД никаких проблем не выявлено.

ошибка в запросе? ошибка в написании компонента делающего запрос? компонент не цепляется к базе?

связка с базой в однопоточном режиме?

нет связи с базой вообще?)) но тогда должно прилетать 500. наверное.

Используя нормальное распределение:

stubFor(get(urlEqualTo("/random/delayed")).willReturn(
        aResponse()
                .withStatus(200)
                .withLogNormalRandomDelay(90, 0.1)));

Тут значение медианы - 90, а сигма = 0,1
И оперируя ими можно как-то подобрать значение в 95%%, 99%%.
Но расчетов у меня нет.

я как раз сейчас с этим ковыряюсь. Мне нужно, чтобы 95%% проходили нормально, а 5%% выполнялись с определенной задержкой
и я пока не оч понимаю, что здесь значит сигма 0.1
мне например нужно поставить задержку в 10 секунд. Мне сигму в 10.0 ставить?

Не вполне понятно что такое "компонент", но предположу, что это какой-то условный микросервис, тогда:
1) Ошибка в запросе - вряд ли, так как тогда это отразится в логах бд
2) ошибка в написании компонента - вполне возможно. Там могла закончиться память/мог случиться дедлок/что угодно еще
3) Компонент не цепляется к базе - почему он цеплялся а потом перестал? Что у нас отвечает за подключение к бд - параметры подключения (не могли измениться), креды (не могли измениться. Что могло быть - закончился коннекшен пулл на стороне БД, однако это было бы видно в БД.
4) Однопоточный режим - хз, я бы просто сказал что производительность компонента может быть ниже производительности системы (он является узким местом)
5) Нет сыязи с базой - в логах компонента были бы ошибки связанные с этим

если у нас есть какой нибудь менеджер очередей, может ли быть затык там?

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

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

Логи будут показательные