Сколько ж я раз ее уже выпиливал из проектов где она как 5 нога для собаки (скорее как яхта в болоте на даче). В проектах не уровня тяжелого энтерпрайза, где есть люди хорошо в нее умеющие (включая аналистов умеющих в bpmn), профит который она дает не стоит колоссальных инвестиций времени разработчиков в ее базовое понимание, так же как и существенного роста стоимости поддержи (привет распределенные транзакции и бэкапы баз, которые нельзя снять одномоментно). Обычная стейт машина в базе решает 95% быстрее и лучше (хотя и требует кода и настроек).
Зачем вообще смешивать эти понятия. Проджект не нужен в Scrum по определению - там есть место только продакту и полнофункциональной команде. И продакт != проджект. У них сильно разные цели и методы. Хотя описанное в статье явно выдает боли и того и другого сполна. Просто потому что бизнес тоже в большинстве случаев сам себе не злобный буратино и ситуативно производит подмену понятий.
Серьезные тесты стоят серьезных денег. Да и не релевантны они для большинства. Нормальные бизнеса сами себе тесты ставят на своем характере нагрузок на различном железе. И для измерения пикового перфоманса и для нагрузочных тестирований сутками гоняют нагрузку в 70-80% от максимальной. Но это совсем другая история. И только там где это реально стоит денег / может иметь эффект большин финансовых и репутационных рисков.
Други, вот читаю я статьи (и за плечами 15 лет оптимизации производительность MS SQL Server под сотни различных платформ начиная с серверов с 1гб озу и винчестерами на борту). И сразу вспоминается случай из жизни когда один довольно крупный банк сделал серьезные инвестиции в абсолютно свежую архитектуру Intel где процессоры были с огромным (40-80) кажется количеством ядер. И с удивлением обнаружил, что процессы которые он так хотел ускорить своими инвестициями под 1мио зелени, на самом деле замедлились примерно в 2 раза. Прозорливый человек сразу найдет ответ - частота процессоров с бОльшим количеством ядер была практически в 2 раза ниже нежели использовавшееся в предыдущем поколении 6-ядерников. К чему все это - "производительность" серверов БД измеряется количеством транзакций в секунду только в крайне ограниченном и довольно редком спектре сценариев. Для 70% бизнесов гораздо бОльшей ценностью будет обладать банальная большая тактовая частота и конечно же более быстрые диски (и их близость к процессору, поэтому NVME). Именно поэтому существует не 1 единственный и достаточный тест TPC, а довольно большое количество профилей. PS из личного опыта PG прекрасен даже в базовых настройках если ставишь его просто на актуальный (в плане архитектуры) сервер ценой условно 100 долл/мес. И дальше любые проблемы перфоманса - это на 95% кривые руки разработчиков. Именно в настройки/ограничения сервера еще ни разу не видел чтобы упирались. Даже финансовые брокера с огромным потоком заявок сделок которые процессятся (и учет и риск-мендежмент) через функции в PG вполне себе могут использовать стандартные настройки и типовое железо. Да и нужно понимать, что любой труд по "оптимизации" должен быть оправдан. И если раньше стоимость сервера для бизнеса была сопоставима с полугодовой зарплатой "оптимизатора", то сейчас все поменялось. И любые попытки меряться транзакциями в секунду вызывают только немой вопрос - "у вас это хобби (за месяц изысканий добиться +5% пикового перфоманса) или я тупой, но покажите мне бизнес, где выгодно это оплачивать (при том что бизнес никогда не живет в пиковых производительностях - уже при 60-70% нужно начинать действия по изменениям)?"
Сколько ж я раз ее уже выпиливал из проектов где она как 5 нога для собаки (скорее как яхта в болоте на даче). В проектах не уровня тяжелого энтерпрайза, где есть люди хорошо в нее умеющие (включая аналистов умеющих в bpmn), профит который она дает не стоит колоссальных инвестиций времени разработчиков в ее базовое понимание, так же как и существенного роста стоимости поддержи (привет распределенные транзакции и бэкапы баз, которые нельзя снять одномоментно). Обычная стейт машина в базе решает 95% быстрее и лучше (хотя и требует кода и настроек).
Зачем вообще смешивать эти понятия. Проджект не нужен в Scrum по определению - там есть место только продакту и полнофункциональной команде. И продакт != проджект. У них сильно разные цели и методы. Хотя описанное в статье явно выдает боли и того и другого сполна. Просто потому что бизнес тоже в большинстве случаев сам себе не злобный буратино и ситуативно производит подмену понятий.
Серьезные тесты стоят серьезных денег. Да и не релевантны они для большинства. Нормальные бизнеса сами себе тесты ставят на своем характере нагрузок на различном железе. И для измерения пикового перфоманса и для нагрузочных тестирований сутками гоняют нагрузку в 70-80% от максимальной. Но это совсем другая история. И только там где это реально стоит денег / может иметь эффект большин финансовых и репутационных рисков.
Други, вот читаю я статьи (и за плечами 15 лет оптимизации производительность MS SQL Server под сотни различных платформ начиная с серверов с 1гб озу и винчестерами на борту). И сразу вспоминается случай из жизни когда один довольно крупный банк сделал серьезные инвестиции в абсолютно свежую архитектуру Intel где процессоры были с огромным (40-80) кажется количеством ядер. И с удивлением обнаружил, что процессы которые он так хотел ускорить своими инвестициями под 1мио зелени, на самом деле замедлились примерно в 2 раза. Прозорливый человек сразу найдет ответ - частота процессоров с бОльшим количеством ядер была практически в 2 раза ниже нежели использовавшееся в предыдущем поколении 6-ядерников.
К чему все это - "производительность" серверов БД измеряется количеством транзакций в секунду только в крайне ограниченном и довольно редком спектре сценариев. Для 70% бизнесов гораздо бОльшей ценностью будет обладать банальная большая тактовая частота и конечно же более быстрые диски (и их близость к процессору, поэтому NVME). Именно поэтому существует не 1 единственный и достаточный тест TPC, а довольно большое количество профилей.
PS из личного опыта PG прекрасен даже в базовых настройках если ставишь его просто на актуальный (в плане архитектуры) сервер ценой условно 100 долл/мес. И дальше любые проблемы перфоманса - это на 95% кривые руки разработчиков. Именно в настройки/ограничения сервера еще ни разу не видел чтобы упирались. Даже финансовые брокера с огромным потоком заявок сделок которые процессятся (и учет и риск-мендежмент) через функции в PG вполне себе могут использовать стандартные настройки и типовое железо. Да и нужно понимать, что любой труд по "оптимизации" должен быть оправдан. И если раньше стоимость сервера для бизнеса была сопоставима с полугодовой зарплатой "оптимизатора", то сейчас все поменялось. И любые попытки меряться транзакциями в секунду вызывают только немой вопрос - "у вас это хобби (за месяц изысканий добиться +5% пикового перфоманса) или я тупой, но покажите мне бизнес, где выгодно это оплачивать (при том что бизнес никогда не живет в пиковых производительностях - уже при 60-70% нужно начинать действия по изменениям)?"