...

CPS Core Performance

Test Environment

TODO: TO DO Laptop specs

The performance tests are written in Groovy (a JVM language). As all CPS Core operations are synchronous, the results here are to be considered as single-threaded operation only.

...

• Storing data nodes has linear time complexity (as expected).
• Raw performance is roughly 3000 fragments per second for the given test setup.
• Performance can be improved by enabling write batching (CPS-1795)
• There are edge cases with exponential complexity.

Commentary

The current database schema does not allow for Hibernate to use JDBC write batching. There is work in progress to address this.

JPA/Hibernate is not well-suited to tree-structured data. As an example, writing data nodes / fragments happens in two low-level steps:

• SQL INSERT to create the fragments
• SQL UPDATE to set the parent IDs of those created fragments
• meaning each created fragment requires two DB operations

There is work in progress to address this behavior using a custom algorithm using JDBC. The use of a graph database would implicitly fix such issues.

Updating data nodes

In this scenario, 1000 Open ROADM device nodes are already defined. A number of these existing data nodes will be updated using CpsDataService::updateDataNodeAndDescendants.

...

• Updating data nodes has linear time complexity (as expected).
• Raw performance is roughly 600 fragments per second for the given model and test setup.
• Updating data nodes is 5 times slower than storing data nodes.

Commentary

This is the weak spot of all write operations. A custom algorithm comparing existing data against updated data (delta algorithm) may be required to improve performance here.

This could also indicate that Hibernate is not being used effectively.

Updating data leaves

In this scenario, 1000 Open ROADM device nodes are already defined. The data leaves of a number of these existing data nodes will be updated using CpsDataService::updateNodeLeaves.

...

• Updating data leaves has linear time complexity.
• Raw performance is about 3000 fragments per second.
• This is very fast compared to updating whole data nodes. I recommend that NCMP use this API for updating CM-handle state.

Commentary

The performance of this function is excellent, and yet it may be improved by write batching.

Deleting data nodes

In this scenario, 300 Open ROADM device nodes are already defined. A number of these data nodes will be deleted using CpsDataService::deleteDataNodes. The types of nodes will be varied, for example, deleting container nodes, list elements, or whole lists.

...

This should narrow the performance gap in this case.

Cps Path Queries

TO DO

There have been massive orders-of-magnitude improvements to query performance. Formerly, queries had quadratic complexity, which is now linear. In the last month alone, performance has improved by 100x.TODO

Comparison of NCMP Performance across versions

...