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 16
Next »
References
CPS-2169
-
Getting issue details...
STATUS
Issues & Decisions
| Issue | Notes | Decision |
---|
1 | Review the use case returning all 50k cmHandle | Validity of the use case where ALL 50k CMhandles are expected to be returned everytime ? AP Csaba Kocsis & kieran mccarthy AP CPS to report where they think scalability issues will occur. TBC kieran mccarthy | |
2 | Proposal to remove hazelcast for NCMP Module sync | The use of Hazelcast during NCMP's CM-handle Module Sync is leading to: High memory usage during CM-handle registration Consistency problem Poor load balancing between NCMP instances for module sync
Proposal to remove hazelcast from NCMP Module Sync requires an LCM State Machine Change. Need stakeholder input. Proposal: CPS-2161: Remove Hazelcast from NCMP Module Sync | |
Requirements
Functional
| Operations | Parallel/Sequential | DMI Delay | Response Size | Performance | Additional Information | Signoff |
---|
1 | Registration & De-registration (Discovery) In Batch size of 100 per request. With moduleSetTag & With alternateID
| Parallel | | | How long should it take cmhandle to reach in ready state - 11 Cm Handles/second per NCMP instance. Base: Average: Peak: Overall budget; a. Advise → locked → Ready: b. Advise → Ready:
| | |
2 | CM-handle ID Search | | | | | Frequency will increase by 2.5 of current capacity Search shall return all 50k searches ? Searches shall return all 50k searches within 1 minute max TBD
| |
3 | CM-handle search | | | | | Frequency will increase by 2.5 of current capacity - CPS-391Spike: Define and Agree NCMP REST Interface - Developer Wiki - Confluence (onap.org) Search shall return all 50k searches ? Searches shall return all 50k searches within 1 minute max TBD
| |
4 | Synchronous single CM-handle pass-through write (CUD) | | | | | Review; the current FS numbers What will be frequencies for write req. ? TBD Frequencies will increase (2.5) of current performance of 25 request/sec= 62.5req/sec Response time should stay the same as current - NCMP Characteristics
| |
5 | Synchronous single CM-handle pass-through Read | | | | | Frequencies will increase (2.5) atm TBC Response time should stay the same as current NCMP Characteristics (delay, size)
| |
6 | Batch Read Operation/Legacy | | | | | Frequencies will increase (2.5) Same load 200 per request Same duration of test Responses are expected back in 80 sec.
| |
7 | CM change Notification Event NCMP shall support a CM notification load of 150 million CM change notifications per day with an average of 870 notification NCMP shall support a peak CM change notification load of 7k/s for a duration 5 minutes
| | | | | 2,175 / sec (base/Average load) 8.75 k/sec (peak load) TBC kieran mccarthy
| |
Error Handling
| Scenario | Expected Behavior | Notes | Signoff |
---|
1 | | | | |
Characteristics
| Parameter | Expectation | Notes | Signoff |
---|
1 | | | | |
Robustness
| Scenario | Input Load | Performance | Notes | Number of NCMP Instances | Signoff |
---|
1 | Base Performance & Performance | | | | | |
2 | Average Performance & Duration | | | | | |
3 | Peak Performance & Duration | | | | | |
4 | Number of Instances | | | | TBC - Each NCMP instance takes 11 CM-Handles/second. | |
Out of Scope
Datajob which is still in development are out of scope
For now Paging is out of scope, open to rescope depending on NCMP spike result
Solution Proposal