...
A varying number of Open ROADM device nodes will be stored using CpsDataService::saveData.
Created device nodes | 1 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | 1000 |
---|---|---|---|---|---|---|---|---|---|---|---|
Time (seconds) | 0.30 | 2.36 | 4.36 | 7.15 | 9.76 | 11.50 | 14.77 | 18.43 | 19.79 | 22.16 | 26.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 (adding books to the bookstore model).
Commentary
The current database schema does not allow for Hibernate to use JDBC write batching. There is work in progress to address this.
...
In this scenario, 1000 Open ROADM device nodes are already defined. A number of these existing data nodes will be updated using CpsDataService::updateDataNodeAndDescendants.
Updated device nodes | 1 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | 1000 |
---|---|---|---|---|---|---|---|---|---|---|---|
Time (seconds) | 0.22 | 12.79 | 28.38 | 44.23 | 51.55 | 69.46 | 85.67 | 95.02 | 109.16 | 117.00 | 131.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.
...
Code Block | ||
---|---|---|
| ||
{ 'openroadm-device': [ {'device-id':'C201-7-1A-1', 'status':'fail', 'ne-state':'jeopardy'} ] } |
Test Results
Updated device nodes | 1 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | 1000 |
---|---|---|---|---|---|---|---|---|---|---|---|
Time (seconds) | 0.20 | 0.27 | 0.28 | 0.28 | 0.32 | 0.38 | 0.39 | 0.47 | 0.49 | 0.52 | 0.56 |
Observations
- 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.
...
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.
Test results
N = | 50 | 100 | 150 | 200 | 250 | 300 | Example xpath |
---|---|---|---|---|---|---|---|
Delete top-level container node | - | - | - | - | - | 0.63 | /openroadm-devices |
Batch delete N/300 container nodes | 0.15 | 0.26 | 0.38 | 0.45 | 0.55 | 0.69 | /openroadm-devices/openroadm-device[@device-id='C201-7-1A-10']/org-openroadm-device |
Batch delete N/300 lists elements | 0.13 | 0.25 | 0.34 | 0.45 | 0.55 | 0.67 | /openroadm-devices/openroadm-device[@device-id='C201-7-1A-49'] |
Batch delete N/300 whole lists | 0.51 | 1.05 | 1.40 | 1.85 | 2.13 | 2.56 | /openroadm-devices/openroadm-device[@device-id='C201-7-1A-293']/org-openroadm-device/degree |
Try batch delete N/300 non-existing | 0.25 | 0.54 | 0.67 | 0.95 | 1.15 | 1.32 | /path/to/non-existing/node[@id='27'] |
Observations
- Delete performance is linear on the amount of data being deleted (as expected).
- Raw performance of deleting containers of list elements is around 40,000 fragments per second. (So we can delete data nodes around 10x faster than creating them.)
- Deleting lists is much slower than deleting the parent container of the list (which 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.
...
Reading the top-level container node with no descendants:
Total device nodes | 500 | 1000 | 1500 | 2000 | 2500 | 3000 |
---|---|---|---|---|---|---|
Time (milliseconds) | 47 | 52 | 48 | 56 | 48 | 47 |
The above data clearly indicates constant time.
Reading the top-level container node with all descendants:
Total device nodes | 500 | 1000 | 1500 | 2000 | 2500 | 3000 |
---|---|---|---|---|---|---|
Time (seconds) | 0.42 | 1.19 | 1.54 | 2.16 | 2.53 | 2.67 |
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.
...
This test uses CpsDataService::getDataNodesForMultipleXpaths with all descendants to retrieve a varying number of Open ROADM device nodes.
Test results
Total device nodes | 500 | 1000 | 1500 | 2000 | 2500 | 3000 |
---|---|---|---|---|---|---|
Time (seconds) | 0.61 | 1.15 | 1.52 | 2.14 | 2.96 | 3.97 |
Special case: attempting to read multiple non-existing data nodes
...