Product Documentation
Abstract
The inital load of the BusinessDataAliasCache, which is an internal cache that is associated with portal queries, scales poorly as the number of named snapshots in the database increases. The performance problem is also associated with large amounts of memory being consumed and heavy load on the database.
Content
The first login to the portal triggers the initial load of the cache and can take a long time. It sometimes results in page time outs and hung thread stack traces in the server log files. During this initial load, there is excessive load on the database. You can see a stack trace similar to the following information:
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesBuilder.processBusinessDataAliasesForSnapshot(BusinessDataAliasesBuilder.java:88(Compiled Code))
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesBuilder.buildBusinessDataAliasesForSnapshot(BusinessDataAliasesBuilder.java:47)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCacheHelper.findBusinessDataAliasesForSnapshot(BusinessDataAliasesCacheHelper.java:36)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/SnapshotBusinessDataAliasesCache.loadCacheData(SnapshotBusinessDataAliasesCache.java:47)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/SnapshotBusinessDataAliasesCache.loadCacheData(SnapshotBusinessDataAliasesCache.java:16)
4XESTACKTRACE at com/lombardisoftware/core/cache/GenericCache.getCacheData(GenericCache.java:170(Compiled Code))
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/SnapshotBusinessDataAliasesCache.getBusinessDataAliases(SnapshotBusinessDataAliasesCache.java:41(Compiled Code))
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesBuilder.processBusinessDataAliasesForBranch(BusinessDataAliasesBuilder.java:69(Compiled Code))
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesBuilder.processBusinessDataAliasesForProject(BusinessDataAliasesBuilder.java:57)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesBuilder.buildBusinessDataAliases(BusinessDataAliasesBuilder.java:40)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCacheHelper.findBusinessDataAliases(BusinessDataAliasesCacheHelper.java:32)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCache.loadCacheData(BusinessDataAliasesCache.java:44)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCache.loadCacheData(BusinessDataAliasesCache.java:11)
4XESTACKTRACE at com/lombardisoftware/core/cache/GenericCache.getCacheData(GenericCache.java:170(Compiled Code))
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCache.getBusinessDataAliases(BusinessDataAliasesCache.java:38)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCache.doInitCache(BusinessDataAliasesCache.java:34)
4XESTACKTRACE at com/lombardisoftware/core/cache/LocalCache.initCache(LocalCache.java:247)
4XESTACKTRACE at com/lombardisoftware/server/core/cache/ServerCoreCache.<init>(ServerCoreCache.java:40)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCache.<init>(BusinessDataAliasesCache.java:22)
4XESTACKTRACE at com/lombardisoftware/server/ejb/psapi/BusinessDataAliasesCache.<clinit>(BusinessDataAliasesCache.java:15)
On runtime servers with many deployed snapshots, large amounts of memory might be consumed, which sometimes leads to out-of-memory errors. Heap dump analysis points to a class named BranchManager as a leak suspect.
The fix
The algorithm for loading and incrementally updating this cache has been optimized to dramatically reduce the number of queries to the database and the server time needed to process the results.
The fix also addresses the memory leak by avoiding the code path that exposed the leak and by putting a configurable bound on the number of entries in the BranchManager cache.
On systems with very large number of snapshots and versions of business process definitions (BPDs) (especially Process Center), the first login to the portal after a server start might still have a delay.
Further tuning to reduce heap consumption
The BranchManager cache is designed to hold certain metadata about the contents of snapshots in memory to improve performance of certain operations. This fix introduces a new configurable property that limits the number of "branches" that the system holds in memory at one time. If, after applying this fix, heap consumption by the BranchManager is still a concern, you can do some additional tuning to further adjust the memory footprint to fit the needs of your environment.
- <branch-context-max-cache-size> property
This property determines how many "branches" are stored in a cache that evicts old entries using a least-recently-used policy. The default value is 64.
In Process Center, a "branch" maps to a workspace. By default, each process application or toolkit has a single workspace named "Main." However, it is possible to enable the creation of additional workspaces. The optimal setting should be large enough to accommodate the number of process applications and toolkits that are actively being developed, viewed, or opened in the authoring environment on any given day.
In a Process Server runtime, however, each deployed snapshot is flattened into its own branch. Thus, the total number of branches roughly equates to the number of deployed process application snapshots. The toolkits shared by these process applications also figure into the total. In general, the system only needs to access just the most recent and active snapshots, so there is little value in holding onto cache data for many old, inactive snapshots. If process applications being deployed are very large, it might be necessary to reduce the default value to a smaller number. To avoid impacting performance, the value should be large enough to comfortably accommodate the snapshots, and dependent toolkit snapshots, that are actually in use. - <snapshot-cache-size-per-branch> property
If heap utilization is a problem in Process Center, then the
<snapshot-cache-size-per-branch> property might need to be tuned. The behavior of this property has not changed with this fix, but it is worth mentioning it because both settings affect how memory is used by the BranchManager cache. This setting controls the number of snapshots that are cached in memory for a single workspace. The default value is 64. If you are developing an especially large process application or toolkit, decreasing this value should reduce the memory footprint. However, reducing this value can negatively affect the performance of operations that involve looking at historical snapshots.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg27025011