This is one of the data gathering methodologies and recommendations for functional performance improvement. The full list is defined in the Performance Recommendations topic.
The base setup of the contexts and dimensions, product and entity data model, assets and classifications are based on business requirements. Nevertheless, the base setup should also be designed based on performance since a complex base setup can have a negative impact on general performance.
An analysis of the base setup is worthwhile, as changes on the base setup for performance reasons usually have a great impact.
For example, changing the data model may impact attributes and references, but can also impact business rules, workflows, Web UI configurations, exports, and imports.
Oracle KODO Database Layer
The Oracle KODO layer is the database layer which allows for Java Persistence API (JPA) specification and Java Data Objects (JDO). By default, the Oracle KODO layer has a cache of 10,000 data relations on an object. An excess of 10,000 relations overwhelms the cache and negatively impacts performance. Examples include a hierarchy with more than 10,000 children, a product with more than 10,000 references, a list of values with more than 10,000 values, and an outbound integration endpoint with a batch size of more than 10,000 events.
Storing large data relations can have a significant negative performance impact due to the likelihood of having a large number of the related objects that are no longer in the cache.
If your system performance is significantly impacted due to this limitation, contact Stibo Systems Support to request a configuration setting to increase the data cache size in the sharedconfig.properties file.
Important: Always weigh the pros and cons of changing the base setup prior to making the change, and test the effects on a lower system before making change on a production system.
For detailed information, refer to the following topics: