Комментарии 9
Очень жду следующей части!
Интрига
А какую базу использовали?
И пробовали-ли оптимизировать базу?
С ваших слов, при большом количестве задач поиск в базе занимал значительное время.
Может быть оптимизация поможет?
не откусывай больше, чем можешь проглотить
Глотаете не жуя? :)
Корректная фраза: bite more than you can chew - укусил больше, чем можешь пережевать.
Спасибо за комментарий! Да, мы пробовали настроить более агрессивный автовакуум, чтобы почаще чистить мусор(у нас Postgres), но результат нас не порадовал: прирост был всего на пару процентов, то есть в рамках погрешности
Думали над добавлением новых индексов, но с этим возникли сложности:
В Camunda из коробки уже есть все необходимые индексы на таблицу act_ru_job, здесь мы не нашли возможностей для улучшения. Но возможно они есть, и мы плохо искали)
Сложно комплексно мониторить перфоманс при добавлении индексов. Например, если у нас получится ускорить чтение Job'ов, мы случайно можем резко замедлить вставку при батчевых операциях, таких как миграции на новую версию схемы
Мы скоро планируем добавить приоритезацию Job'ов, и она потребует замены индексов в act_ru_job. Есть риск вернуться к проблеме, так как запрос на поллинг Job'ов изменится
А вот по фразе из заголовка мной было проведено отдельное расследование на эту тему еще перед публикацией)
В большинстве упоминаний в русскоязычных источниках используется именно 'проглатывать', но вы правы, что правильнее было бы перевести как 'пережевать'. Оставил как привычнее народу)
Моё мнение, вы просто ошиблись с архитектурой решения и не учли потенциальную нагрузку с учетом роста. По факту просто уперлись в производительность постгреса. Даже если вы сейчас потюните что-то, то это спасёт только на время. При подаче нагрузки ещё x2 у вас опять всё сляжет. Тут или использовать in-memory оркестраторы бп с такими же бд или всю оркестрацию бизнес процессов строить самим на базе Кафки.
Слышал, что сбер сделал свой bpmn движок platform v flow как раз на базе Кафки избавившись от бд, где все состояния бп в кафке и хранятся. Видимо тоже уперлись в бд...
Спасибо за статью со столь нлубоким описанием.
Вы правы, данная ситуация не уникальна и многие с ней сталкиваются.
Вы правы, настройка должна быть включена. Можно еще принудительно проверять dueDate в диаграммах перез заливкой в репозиторий.
В настройках Kafka слушателя уже есть поддержка мультипоточности и максимального количества потоков. Настройка слушателя необходима, т.к. всегда есть аппаратные ограничения.
Нужно блюсти баланс и, вы правы, просто увеличение пула не решает проблемы
А вот здесь, как раз, и кроется основная проблема и основнаое решение - нужно уменьшить количество висящих процессов. Супер база и железо быстрей обработает ваши сотни тысяч процессов, но и их возможности ограничены. Технические решения могут только на время улучшить картину, но не решат логические ошибки.
В одной компании с сотнями тысяч сотрудников была такая же проблема. Казалось, проще простого стартовать на каждого сотрудника экземпляр процесса и дело с концом. Но...
При увеличении количества сотрудником количество процессов будет расти
При завершении и старте нового периода количество процессов может удваиваться
Если нужно передеплоить новую версию процесса, например, нашли ошибку в логике, то получаем тот же массовый эффект.
Сама по себе поддержка сотен тысяч процессов затратное дело.
При анализе процессов оказалось, что уникальных типов процессов с режимами ожидания всего не более 20ти. Простая переделка процессов решила все остальные. Процесс по времени шлет уникальные сообщения на каждого сотрудника и сообщения стартуют процессы с короткими транзакциями.
Основной совет - не смешивать реалтайм и обработку с таймерами в одном процессе.
Спасибо за подробный комментарий! Рад что статья собирает людей, кто уже имел дело с этой проблемой, надеюсь это будет тот случай, когда комментарии будут полезнее самой статьи)
Процесс по времени шлет уникальные сообщения на каждого сотрудника
Можете здесь чуть подробнее объяснить, как вы шлете сообщения в нужное время? Мы просто такие вещи обычно делаем на таймерах , и я пока не представляю как без них обойтись в такой ситуации
Или может есть какие-нибудь универсальные подходы по избавлению от таймеров, или здесь все индивидуально от сервиса к сервису?
У нас вот много циклических ежедневных таймеров, и у меня была мысль заменить их ожидающий MessageEvent. И в приложении добавить простой советский Schedulled Job от Spring, который будет находить все активные процессы и коррелировать в них сообщения. Таблица act_ru_job сильно похудеет, так как процесс висящий на ожидании сообщения не создает джобу
Добрый день! Большое спасибо за статью, было интересно прочитать. Если я правильно понял, то вы используете делегаты, в таком случае действительно не помогает увеличение потоков в пуле без увеличения числа соединений БД, тк поток, если мне не изменяет память, забирает соединение целиком и полностью, пока не завершит джобу, так что прирост сложно ощутить.
Рассматриваете ли вы переход с делегатов на external task? С ними и на 8 версию можно будет переходить) У нас была похожая проблема, мы ее решили в том числе переходом на external task, тк коннекты к БД были задействованы только для поиска задач и сохранения результата, а во время исполнения задачи освобождались. Замеряли потом нагрузочные тестированием и выявили, что таким образом можно кусать куда больше. В целом подход с внешним исполнением позволяет больше обрабатывать, но требует и большей зрелости, тк начинается пляска с блокировками задачами и идемпотентностью. Но бесконечно не замасштабироваться, тк в конце упремся в БД все равно. Где-то были записаны замеры, получали в районе х4-х10 при разных проблемах, но это уже тема для другой статьи)
Привет, спасибо за комментарий! Да, external таски нам советовали, слышал что некоторые команды внутри банка перешли полностью на них, но нам к сожалению пока не удалось с ними поработать
Полный переход на них нам дорого обойдется, у нас за год уже больше 70 делегатов накопилось и они продолжают расти чуть ли не с каждым днем. Если получится протестить на отдельных процессах, то отпишусь сюда об ощущениях)
Звучит действительно как крутая тема для отдельной статьи, по типу Delegate vs External Task с замерами по производительности. Было бы круто, если бы вы пошарили свой опыт по переходу на них, мы наверное не скоро до них доберемся
Camunda и Kafka: не откусывай больше, чем можешь проглотить