...
Issue | Notes | Decision | |
|---|---|---|---|
| 1 | Calls to DB for modules (in check existing tag)Tag) | Could easily cache Module Set Tag in memory to reduce this | |
| 2 | First batch (on each thread) calls to DMI for same Tag | Use cache from #1 or store first cm Handle in DB immediately instead of as part of Batch | |
| 3 | Store new schemaset schema set for each cm handle (instead of Tag) | Use schema set concept (in CPS Core) to only store each new Module Set Tag once. This seems the correct usage of Schema Set concept and wil have the greatest performance benefit. This requires more costly and difficult solution as NCMP code is develop assuming each cm handle schema set name is the same as its id.
|
Analysis
A small Spock&Groovy integration test as been created to sync a few hundred cm handles with multiple threads. See https://gerrit.onap.org/r/c/cps/+/139344
Test Setup
Parameter | Value | Notes |
|---|---|---|
Cm Handles | 500 | |
Module Set Tags | 2 | 250 CM Handles Each |
Worker Threads (parallelism) | 2 | |
Environment | Windows 11. 13th Gen Intel(R) Core(TM) i9-13900H 2.60 GHz |
Measurements
average of 4 runs
Method | Time Spent (ms) | % | Notes |
|---|---|---|---|
query module references | 1,017 | 7% | |
get modules from DMI | 1,326 | 9% | Fake response, no delay |
store schema set | 10,449 | 73% | |
update states | 1,429 | 10% | |
Total | 14,221 |
| = 14 Seconds |
Extrapolated Results for 20,000 Nodes and DMI Delay
below figures are calculated by multiplying the total time and adding fix delays for DMI requests
Methods | Time Spent (ms) | % | Notes |
|---|---|---|---|
query module references | 40,670 | 7% | |
get modules from DMI | 54,050 | 9% | add 200ms delay for first 10 batch of 100 |
store schema set | 417,960 | 73% | |
update states | 57,170 | 10% | |
Total | 569,850 |
| ~ 9.50 Minutes |