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

Compare with Current View Page History

« Previous Version 7 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 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. Not all results are displayed on this page, but are included in the attached spreadsheet.

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.

Deleting data nodes


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 the 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')

This should narrow the performance gap in this case.

Cps Path Queries


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