Performance issues with large number of rulesets and applications
We are building out a common layer owned by our center of excellence. We are building it out in multiple applications with multiple rulesets. There is an open question about whether or not we will suffer any performance issues as the number of rulesets grows. Currently there are 21 applications that make up the common layer, and as much as possible we don't plan to grow the number much past this. We may consolidate some of the applications, but we might also add a few if the need arises. These applications are comprised of 41 different rulesets and I expect this number to grow. The concern from the application teams that are building on top of the common layer, is will there be any performance hit with this number of rulesets that will grow and the total number of applications?
***Updated by moderator: Lochan to update platform capability***
Pegasystems Inc.
IT
Very good question. The practice of building common foundation layers to support multiple applications is not uncommon in complex Organizations.
Let me say that the fact that the problem is taken into account before it occurs is a very positive factor as you may put in place approaches to prevent it.
This is usually not a problem in production environments where rules are not changed very frequently and the same rules are executed repeatedly. This ensure that the rules cache have a high hit rate with few rules needing to be assembled and compiled on first use.
In my experience problems may arise mostly during development especially when many development teams are working concurrently performing refactoring tasks on several branch rulesets (hundreds of them).
This may generate a database load that slow down the development environment.
Fortunately the following corrective actions can be used to prevent the issue and address it as soon as it starts to manifest.
Very good question. The practice of building common foundation layers to support multiple applications is not uncommon in complex Organizations.
Let me say that the fact that the problem is taken into account before it occurs is a very positive factor as you may put in place approaches to prevent it.
This is usually not a problem in production environments where rules are not changed very frequently and the same rules are executed repeatedly. This ensure that the rules cache have a high hit rate with few rules needing to be assembled and compiled on first use.
In my experience problems may arise mostly during development especially when many development teams are working concurrently performing refactoring tasks on several branch rulesets (hundreds of them).
This may generate a database load that slow down the development environment.
Fortunately the following corrective actions can be used to prevent the issue and address it as soon as it starts to manifest.
- Monitor the database by using database specific performance gathering and reporting tools (AWR Reports, Data collector reports, Server Activity, Query Statistics, Disk usage information on SQL instance,...)
- Monitor the Pega nodes by using AES or PDC
- Proactively maintain the ruleset base: Skim old rulesets, Reduce the number of branches by merging old ones
- Apply DevOps best practices: Split the system into multiple ones. This is the recommended approach in case of multiple development teams. According to the Community Article Development workflow in the DevOps pipeline "If you have multiple teams working on the same application, each team should have a separate development server. A central Pega server acts as a system of record (SOR). "