...
Follow principles/patterns of RESTCONF RFC-8040 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of yang-patch RFC-8072 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of RESTCONF NMDA RFC-8527 https://datatracker.ietf.org/doc/html/rfc8527
Requirements
| Note |
|---|
Please note this section was added long after the implementation and focuses on characteristic only. |
Characteristics - WIP
It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.
...
Expected duration
...
100 ms to get module references
1000 ms to get module resources
...
N/A
...
N/A
...
N/A
...
5
...
20
...
TDB e.g. 5 KB
...
25 op/sec
...
20
...
N/A
...
within 1 sec
...
20
...
N/A
...
13 ops/sec
...
20
...
Within 2 sec
Note
- This is for mixed TCs
- Single KPIs will be monitored in NCMP owned pipeline with our performance every day(2 hrs interval) - Performance
- New BATCH KPI - TBD
- Organise a call to walk through the code and TCs with //. Want to see the code of the Test Cases. Csaba Szabó to walkthrough TCs with CPS team
- Check Registration & de-reg agree with //
Open Questions
- Concurrent which number are we agreeing to test, 10 parallel op. according to the input load, the average response time as mentioned in comment is 20 parallel op
- DMI delay - We need feed back from ETH on this
- Better to have R, W use cases separated as in the FS for both throughput and response time or should we merge this on NCMP
- Check Registration - Kolawole Adebisi-Adeolokun Refer to Michelle's email
- Check DE-Registration if this was ever agreed
Ongoing Discussion
- Share Test cases per KPI with CPS. AP @Csaba Szabó X to walkthrough TCs with Toine & Daniel(CPS)
- Functional Specification document.
- Confluence: Configuration Handling Functional Specification.
i. Current content shows mixed testcases, all TCs happening in parallel. AP @Csaba Kocsis Clarify what is being run in parallel and update table accordingly.
ii. AP @Csaba Kocsis update UseCase_0005_IdSearch_NoFilter & UseCase_0008_Search_NoFilter to merge the Input Load column to show total of 5 parallel requests.
iii. AP @Csaba Kocsis Notify Product Engineering (Dagda) about the change.
- AP , @Csaba Kocsis , @Toine Siebelink, @Kolawole Adeolokun: Review the FS and identify if additional information is required. ONGOING
i. 23rd April: FS reviewed and 2 comments added by Toine.
- Question about FS and Stability test strategy – what is expected to be supported in parallel or what is expected to be tested in series? How is that decided? AP Michelle & @Csaba Kocsis
...
Issues & Decisions
| Issues | Notes | Decisions | |
|---|---|---|---|
| 1 | KPI for De-registration of 100 CM-handles | This was mentioned. Was this ever agreed, is this a valid use case that needs to be covered together with the Registration ? | Not priority for now, but acceptable if we match the registration req. |
| 2 | DMI delay | Could we get some feedback on DMI-delays for other use cases as not mentioned in FS document | Awaiting for ETH feedback AP On Kolawole Adebisi-Adeolokun and Csaba Kocsis Provided |
| 3 | Number of instances In some cases, ETH have used 2 instances, can we verify the number of instances for each use case. Some of the req were defined per instance and resources used : Identify which of these ? | Agreed to; CPS use 1 instance currently, but should focus on aligning performance with 2 instances for all use case | |
| 4 | Input Load Distribution the CM-handle search and ID search | Currently has 5 parallel request between them distributed at 2.5 each. This fractional distribution isn't feasible for parallel processing; the load should be allocated as whole numbers. Load needs to be distributed at. Would it be acceptable to adjust this distribution to either 2 or 3 parallel requests each (and vice versa ) without any negative repercussions? Agreed to do 6 parallel request combined total and divide the load to 3 parallel request each | |
| 5 | Regarding CM-handle search and ID search | FS only identified Module performance, are there any testing done towards a combined search of properties and modules in a single query Confirmed no other testing was previously done on this..... CPS have the capabilities to do mixed testing. ETH tbc on if they want to consider this ( Csaba Kocsis ) |
Requirements
| Note |
|---|
Please note this section was added long after the implementation and focuses on characteristic and enhancements after this study only. |
| Excerpt Include | ||||
|---|---|---|---|---|
|
Characteristics
It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.
| Operation | Concurrent requests/parallel | DMI Delay | Response size | Performance Requirement (Blue Stone tablet KPI) | Notes | Sign-Off | |
|---|---|---|---|---|---|---|---|
| 1 | Registration of 20,000 CM-handles (in batches of 100) | 1 (requests are sequential) | 100 ms to get module references | N/A |
|
| |
| 2 | De-registration of 100 CM-handles | 1 (requests are sequential) | No Module delays | N/A |
| De-registration is currently not mentioned in Stone Tablet KPI or FS, however we have agreed to match the performance of registration for now as de-reg is also not a priority at this point in time | |
| 3 | CM-handle ID search with Module filter | 3 | N/A | 20,000 CM Handles i.e. 100*20.000 = 2MB | As provided byCsaba Kocsis 0.625 seconds/Operation | FS stated 5 parallel request for both ID search and search. CPS to run with 3 parallel each for both ID search and Search meaning a combine total of 6 parallel request | |
| 4 | CM-handle search with Module filter | 3 Run in parallel with #3 | N/A | 20,000 CM Handles i.e. 500*20.000 = 10MB | As provided by Csaba Kocsis 13 seconds/Operation | FS stated 5 parallel request for both ID search and search. CPS to test with 3 parallel each for both ID search and Search meaning a combine total of 6 parallel request | |
| 5 | Synchronous single CM-handle pass-through read | 10 | 300 ms Csaba Kocsis | 5 KB | 25 (parallel) request/sec | Read are done in parallel with Write | |
| 6 | Synchronous single CM-handle pass-through write (CUD) | 10 | 670 msCsaba Kocsis | 5 KB | 13 (parallel) request/sec | No response is expected | |
| 7 | Batch/Bulk Read | 1 read request with 200 cmHandle per second | 150 cmhandles/sec |
Notes
- This is for mixed TCs
- Single KPIs will be monitored in NCMP owned pipeline with our performance every day(2 hrs interval) - Performance
Synchronous single cm-handle pass-through (read) requests
...