я не знал, узнаю все как всегда последний

"пиши потом разберемся!"

Возьми heidisql и там дамп сделай

Добрый день!
Подскажите, что можно почитать, посмотреть на тему замеров производительности сервисов, баз, серверов и т.д.

Т.е., как правильно считать максимальное количество RPS (requests per second) на машину, или наоборот, как подобрать машину, если даётся требование по RPS, по времени обработки, по SLA и т.д.?

Все это руками и нагрузочными тестами считается или есть какие-то более формальные подходы/методики?

Метрики и профайлеры

Да, я в курсе, что в эту сторону копать. А вот конкретней умные книжки там или чтиво какое-нибудь можете порекомендовать?)

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

https://t.me/devops_ru )

Google SRE book

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

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

Можно руками (промитей или логи парсить) можно подключить какой ньюрелик или всякие dynatrace и там настраивать штуки

Нагрузочные тесты сделать тоже придется.

У newrelic неплохие агенты, да. Плюс там всякие APM есть.
Для нагрузочных можно loader.io

Яндекс танк не пойдет?

Вполне. Было лень для него конфиги писать)

Можно и siege обойтись, не совсем честно, конечно)

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

Кто такие дэвопсы? Это как опсы только ещё и дэвы?

Вы прекрасно знаете кто такой девопс  но чего то до меня докопались

Добрый день. Хочу понять как правильно организовать получение агрегатов. Сейчас существует такой агрегат - Инцидент. Он представляет собой инцидент ИБ со всякими связями и правилами. И вот в случае если инцидент удаленный (пометка такая) или архивный, правила меняются, в частности его нельзя просто так больше редактировать (под редактированием понимает заполнение набора полей доступных этому инциденту). Сейчас, когда приходит запрос в сервис на изменение, из репозитория инцидентов по идентификатору получаем агрегат Инцидент и выполняем над ним действия. И вот можно было б при попытке редактирования проверять соответсвующие флаги, но как-то не очень мне нравится этот подход. Думаю правильнее будет выделить удаленный и архивный инциденты в отдельные агрегаты типа DeletedIncident и ArchivedIncident, дабы и в будущем упростить реализацию правил только для них. Но тогда не понятно по поводу репозитория, который теперь должен возвращать и Incident и DeletedIncident и ArchivedIncident, что тоже не правильно. Как это лучше разрешить, в какую сторону смотреть?

тож задавался таким вопросом
наверное ответ в том, что раз методы у объектов разные - юзкейсы тоже будут разные. Тогда и репозитории будут разные и методы в апи будут разные. Короче всё отдельно будет.
Тут прикол в том, куда if засунуть по сути.
Можно на клиент (ведь клиент знает с каким типом объекта работает), можно на шлюз какой, если у тебя он есть перед приложением.
Мне кажется, что чем раньше это иф в юзкейсе будет, тем лучше. Т.е. в идеале на клиенте этот иф держать. Или если у тебя бек управляет фронтом (hateoas вот это вот всё) - при генерации экшенов для фронта
но это неточно, сам я такого не делал 🤔