База - бутылочное горлышко! Как решить проблему?

Camunda 7
1

снова привет!

У нас есть высоконагруженный сервис > 500к экземпляров процесса в час. Стали обращать внимание, что в нашем решении запись в базу становится бутылочным горлышком. Рассматриваем возможность использования Zeebea в качестве альтернативы комунде, может быть у кого то есть опыт использования?

2

Здравствуйте!

Чтобы СУБД не становилась узким местом, есть ряд правил, которых стоит придерживаться:

  1. Хранить в переменных процесса только те данные, что используются для принятия решений в процессе. Избегать помещения в контекст процесса больших объектов (или файлов) - хранить только ключ/id объекта, или например, ссылку на файл.

  2. Рационально расставлять точки сохранения (wait states/save point) в процессе. Избегать избыточных точек сохранения. У Camunda есть рекомендации/best practices в этой части:
    Camunda Best Practices - Dealing With Problems and Exceptions

Есть практическое правило ставить признак async = true на все сервисные задачи, но в вашем случае нужен более вдумчивый подход.

Не будучи знакомым с Вашим процессом и имея ввиду только требования к нагрузке, я бы советовал ограничиться общими рекомендациями:

  • asyncAfter пользовательских задач (дополнительно проверьте, чтобы не было asyncBefore - для User Tasks они избыточны)
  • asyncAfter Receive Tasks/Events - по понятным причинам (сохранение полученных данных/сообщений)
  • async after сервисных задач выполняющие идемпотентные действия
  • async before задач, выполняющих сетевые вызовы
  • async before параллельных шлюзов, OR шлюзов, задач имеющих маркер параллельных активностей (предотвращение Optimistic Locking Exception)
  • async after задач выполняющих ресурсоемкие вычисления

Нет смысла маркировать асинхронными задачи, выполняющие какие-то простые, “легкие” вычисления и обратите внимания, чтобы не было избыточных точек сохранения, там где они уже есть (например async before на receive event или user task)

  1. Рациональный уровень истории изменений (аудита). Если вы не Enterprise клиент и не используете Optimize, подумайте о менее детальном уровне истории.

  2. По возможности, вы высоконагруженных процессах избегать использования external task и call activity, тк их вызов создает дополнительные запросы к базе.

Про Zeebee не могу ничего сказать, не имею опыта работы с ней. Не уверен, что это решение ready to production.

3

Добрый день!

высоконагруженный сервис > 500к экземпляров процесса в час

Такая нагрузка идёт постоянно или эпизодически? Просто если это происходит раз в месяц, как в процессе выставления счетов, то может имеет смысл запускать процессы партиями (batches) и ограничить кол-во до 250к экземпляров в час? Да, это увеличит общее время обработки, но какая разница для клиента если он получит счёт в час ночи или в два.

1 лайк
4

действительно, это эпизодическая нагрузка, батч: калькуляция и предоставление выписки.
вы правы, надо поделить эти процессы на порции. :smiley: