Буду признателен про все системы, но в приоритете большие системы

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

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

И составлением краткосрочного и долгосрочного плана управления мощностями.

Сейчас работаю с большими и средними системами. Железа для них надо много, его покупают заранее. И вот его дают. Оно есть, какое-то. Задача - определить возможности того железа, что есть.

Тестирование будет на поиск предела. В возрастающей нагрузкой. Профиль будет таким, что превысит предполагаемый профиль по мнению аналитика (3 сценария в сек) и пойдет дальше, пусть до 10 сценариев в сек.

В это время вы буду мониторить всё, и найдете точку деградации. Ту нагрузку, когда время отклика или количество ошибок станет выше лимита. Пусть это 5 сценариев в сек.

Мониторинг на интенсивности 5 сценариев в сек покажет, что узким местом стал диск. Что очередь диска выросла. И скорость записи была 25 МБайт/сек.

А при профиле нагрузки 3 сценария в сек, скорость была 15 МБайт/сек.

Вот и определите, что скорость записи растет линейно с ростом нагрузки. Ближайшее узкое место - диск. И если нужна производительность х2 нужно либо жать данные (процессором), либо купить диск быстрее.

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

А для систем в контейнерах характеристики режут. И задача теста - найти минимальную конфигурацию по памяти, процессору. Потом будет выведен в работу стенд, где выставлено 0.2 ядра и 270 МБайт ОЗУ. А когда нагрузка превысит профиль в 3 сценария в сек или сработает другой триггер, то добавится ещё 1 контейнер, про который известно, что он добавит ещё + 0-3 сценария в сек.

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

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

Пока профилирование помогает разгонять. И в прод выходят системы, которые держат *5 нагрузки от планируемой или больше.

Но когда систем станет так много, что на профилирование не останется времени. То думаю тестирование станет другим - "Сколько железа минимум нужно для этого микросервиса?" И не важно, что там внутри контейнера. К этому готовлюсь, морально.

Ты описываешь что-то похожее на serverless

Бум микросервисов :)) это пройдет ;)

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

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

https://corp.mail.ru/ru/press/events/devops-2/

Вот тут думаю будет кто-то, кто ответит про практический capacity. Доклады от Райффайзенбанк, Мейл, Росгосстрах. Встреча для тех, кто в Москве 22 августа

Думаю с трансляцией на ютюб будет

Потом будет восстание микросервисов 😂

А записи?

на кубик я ходил)