Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

CPS Core Performance

Test Environment

TODO: 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.

Test data

Test data used complies with OpenROADM YANG model. Specifically, openroadm-device nodes 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 multiple anchors with similar data, up to 3000 device nodes, meaning that the system has been tested up to 1 million fragments.

Storing data nodes

A varying number of OpenROADM device nodes will be stored using CpsDataService::saveData.

Created device nodes11002003004005006007008009001000

Time (seconds)

0.2952.364.367.159.7611.5014.7718.4319.7922.1626.54

Observations

  • 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.

Updating data nodes

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

Updated device nodes11002003004005006007008009001000

Time (seconds)

0.21512.7928.3844.2351.55

69.46

85.6795.02109.16117.00131.15

Observations

  • 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.

Updating data leaves

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

Example JSON payload for updating data leaves for one device:

{
    'openroadm-device': [
        {'device-id':'C201-7-1A-1', 'status':'fail', 'ne-state':'jeopardy'}
    ]
}

Test Results

Updated device nodes11002003004005006007008009001000

Time (seconds)

.201.266.276.280.317.379.385.465.485.520

.561

Observations

  • Updating data leaves has linear time complexity.
  • Raw performance is about 3000 fragments per second.

Reading data nodes

In these tests, a varying number of OpenROADM devices are created and retrieved.

Reading top-level container node

In this test, CpsDataService::getDataNodes is used to retrieve the top-level container node.

Test results

Reading the top-level container node with no descendants:

Total device nodes50010001500200025003000
Time (milliseconds)475248564847

The above data clearly indicates constant time.

Reading the top-level container node with all descendants:

Total device nodes50010001500200025003000
Time (seconds)0.4231.1891.5362.1592.5262.696

Observations

  • Reading a single top-level container node with no descendants has constant time (as expected).
  • Reading a single top-level container node with all descendants has linear time (as expected).
  • Raw performance of reading with all descendants is roughly 100,000 fragments per second.

Reading data nodes for multiple xpaths

This test uses CpsDataService::getDataNodesForMultipleXpaths with all descendants to retrieve a varying number of OpenROADM device nodes.

Test results

Total device nodes50010001500200025003000
Time (seconds)0.6191.1511.5222.1362.9573.965

Special case: attempting to read multiple non-existing data nodes

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

Total devices nodes50010001500200025003000
Time (milliseconds)10109978

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

Observations

  • Reading many data nodes with all descendants has linear time (as expected).
  • Attempting to read many non-existing data nodes takes negligible time.
  • Raw performance of reading many with all descendants is roughly 80,000 fragments per second.

Additional test cases: Reading container node versus list

Recently, functionality was added to enable reading whole lists (CPS-1696). Here we compare performance of reading a container node containing a list, versus reading the list (with all descendants).

Total device nodes50010001500200025003000xpath
Reading container0.3860.7121.5292.6671.7593.112/openroadm-devices
Reading list0.5851.3352.0362.8602.7693.949/openroadm-devices/openroadm-device

As can be seen, it is slower reading a list than reading the parent node containing the list.

Suggested improvement: Add a condition to the WHERE clause in the SQL for reading lists, to narrow the search space to children of the parent. For example:

WHERE (existing conditions)
  AND parent_id = (SELECT id FROM fragment WHERE xpath = '/parent-xpath')

Cps Path Queries


Deleting data nodes


NCMP Performance

CM-handle registration

TODO Comparison of Kohn, London, Montreal (current) up to 40,000 CM handles

CM-handle deregistration

TODO Comparison of Kohn, London, Montreal (current) up to 40,000 CM handles


  • No labels