Ещё есть server sent events, чуть лучше для батарейки

Добрый день!
Подскажите, пожалуйста, что сейчас модно использовать для нагрузочного тестирования и выявления узких мест (канал не выдерживает, IO базы или диска отваливается, и т.д.)?

Есть система, состоящая из нескольких подсистем, на внешку смотрит один модуль, внутри все общается через всякие очереди, http/rest/soap + есть интеграция с ещё внешними системами.

Уже давно в проде, все работает, но на совсем небольших нагрузках - до 500 RPS, что совсем копейки.

Встала задача - запустить это же решение в масштабе другого порядка, до 2-3 миллионов запросов в минуту.

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

Можно в gcloud/aws брать в аренду виртуальные машины, и на них распределенно запускать Locust например. По моему опыту, с одной машины можно выжать 2-3k rps

Принято, посмотрю на locust)

Потому что есть три разных фильтра, каждый из которых очень сильно грузит фронт - поэтому их делаем на бэке

как вы бы решили ситуацию, в которой у агрегат-рута по его бизнес-природе должен быть композитный ключ, но при этом он event-sourced и composite key нельзя?

пример: "респондент" A проходит "опрос" B и нужен агрегат-рут "прохождение опроса" AB.

мои варианты:
- uuid v5, который является чистой функцией от двух uuid-ов
- таблица респондент|опрос|прохождение с idшками

Почему нельзя сделать моноключ конкатенацией его компонентов?

ну по сути это и есть uuid5

Как на счёт
id
surveyId
personId

а зачем uuid5 ? Оттуда потом можно выдрать исходные ключи? Но даже если можно - зачем так запариваться? Нипаняятна

смотри, есть два варианта. либо у меня во всех командах свойства surveyId, respondentId и тогда мне надо найти агрегат-рут по этим двум полям. но поскольку он ES, я не могу сделать запрос where surveyId = B, respondentId = A.

либо я делаю заранее команду "создай прохождение опроса" id = X, surveyId = B, respondentId = A, и потом в командах использую id = X. но тогда я не могу быть уверен, что для B, A существует только один такой агрегат-рут.

важный момент, что уже во время прохождения опроса я не могу сначала создать id, потом его где-то запомнить и начать передавать, так как на прохождение выдаётся ссылка с зашитым jwt и пользователь может несколько раз по ней переходить с разных устройств.

соответственно, либо в первом случае я использую id = uuid5(A, B ) и всегда получаю детерминированный суррогатный ключ от двух полей, либо не сильно парюсь на тему "не могу быть уверен, что для B, A существует только один такой агрегат-рут" и дальше строю систему исходя из того, что прохождений может быть несколько. вот только несколько прохождений ведут к разным рискам, которые сильно могут исказить статистику и тд.

Es, это когда трекаются все изменения?

да, { id, eventStream }, его нельзя запросить по каким-то полям из каких-то событий, только достать по id

Такое редко где нужно применять, как мне кажется.

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

Трекаются изменения полей сущностей?

ну не полей, а по ивентам строятся соответствующие проекции. в таком агрегат-руте нет "полей", это же не стейт, а стрим

Почему у ивент стрима не может быть составного ключа?

хороший вопрос))) потому что у меня такая абстракция)) в рамках которой мне проще взять uuid v5 вместо surveyId.respondentId

в каждой табличке по id и нет проблем)