Table of Contents

Summary

This is an assessment of current performance of CPS operations, as of August 2023.

Since January 2023, performance of many CPS and NCMP operations have been increased by orders of magnitude - some highlights:

• NCMP CM-handle de-registration moved from average quadratic to linear time (constant rate). De-registering 20,000 CM-handles is thousands of times faster now.
• CPS Path Queries have moved from worst-case quadratic to linear time complexity, and best case linear to constant. Queries that took days previously take minutes or seconds now.
• Memory usage during read operations has decreased by more than 90%.
• Not only has performance increased, but reliability and robustness. It is now possible for a single batch operation to handle tens of thousands of elements, where it would have failed before.

CPS Core Performance

Test Environment

...

Test data used complies with Open ROADM YANG model - a real-world model for optical devices. Specifically, openroadm-device nodes, each consisting of 86 fragments, are created. For example, a test that creates 1000 device nodes will result in 86,000 fragments in the database. Some tests use up to 3000 device nodes (258,000 fragments - equivalent to around 20,000 CM-handles in NCMP), with four anchors replicating the data, meaning that the system has been tested up to 1 million fragments.

...

• 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, and should be preferred where possible.

Commentary

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

 I recommend that NCMP use this API for updating CM-handle state.

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.

...

• Delete performance is linear on the amount of data being deleted (as expected).
• Raw performance of deleting container nodes is around 40,000 fragments per second. (So we can delete data nodes around more than 10x faster than creating them.)
• Deleting lists is much slower than deleting the parent container of the list (which this can be easily improved).
• Of note, attempting to delete non-existing data nodes takes longer than actually deleting the equivalent amount of nodes with descendants - it is a slow operation.

...

In this case, we attempt to read many non-existing data nodes:

The above case appears to be constant time, but theoretically must be linear - we'll call it negligible time.

...

...