Skip to end of metadata
Go to start of metadata

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

Compare with Current View Version History

« Previous Version 5 Next »

Overview

This page documents the results of the CM data performance test conducted to evaluate the system's response time under different loads. The tests measured the impact of processing 500 and 1,000 AVC events per second on various CM-handle search and NCMP overhead operations.

Test Details

  • Test Environment: [Nordix-onap-cps-performance-test-k6 ]

  • Load Conditions:

    • No Load: Baseline measurement without additional event processing.

    • 500 AVC events/sec: Moderate load scenario.

    • 1000 AVC events/sec: High load scenario.

  • Metric: Response time in milliseconds (ms) for search and pass-through operations.

  • Objective: Measure performance degradation (percentage loss/gain) under different load conditions.

  • The raw data is in the attached spreadsheet.

Results Summary

CM-Handle ID Search Performance

This test measures the time required to search for a CM-handle ID with different filters.

Test Name

No Load (ms)

500 AVC events/sec (ms)

% Loss/Gain

1000 AVC events/sec (ms)

% Loss/Gain

No Filter

1,003

1,067

-6.4%

1,122

-12.0%

Module Filter

243

259

-6.4%

264

-8.7%

Property Filter

2,233

2,404

-7.6%

2,541

-13.8%

Cps Path Filter

2,276

2,449

-7.6%

2,589

-13.7%

Trust Level Filter

11,353

12,283

-8.2%

13,367

-17.7%

Analysis:

  • All ID search operations show performance degradation as load increases.

  • The Trust Level Filter search has the highest latency, with a 17.7% increase in response time at 1,000 AVC events/sec.

CM-Handle Search Performance

These tests measure search time for CM-handles with various filters.

Test Name

No Load (ms)

500 AVC events/sec (ms)

% Loss/Gain

1000 AVC events/sec (ms)

% Loss/Gain

No Filter

8,393

9,175

-9.3%

9,809

-16.9%

Module Filter

10,578

11,420

-8.0%

12,000

-13.4%

Property Filter

12,499

13,383

-7.1%

14,519

-16.2%

Cps Path Filter

13,017

14,145

-8.7%

14,925

-14.7%

Trust Level Filter

22,222

23,840

-7.3%

25,452

-14.5%

Analysis:

  • Performance degradation is noticeable, especially at 1,000 AVC events/sec.

  • CM-handle search with No Filter shows a 16.9% degradation, indicating it is heavily impacted by load.

  • Trust Level Filter search remains the slowest operation across tests.

NCMP Overhead Analysis

This test measures the additional processing time for synchronous pass-through read/write operations.

Test Name

No Load (ms)

500 AVC events/sec (ms)

% Loss/Gain

1000 AVC events/sec (ms)

% Loss/Gain

Read

34

35

-2.5%

37

-7.5%

Read (Alternate ID)

92

95

-2.9%

98

-6.1%

Write

40

42

-5.6%

46

-14.6%

Write (Alternate ID)

90

97

-7.0%

100

-10.7%

Analysis:

  • Read operations are less affected by load compared to write operations.

  • Write operations, especially at 1,000 AVC events/sec, show a 14.6% increase in processing time.

Legacy Batch Read Performance

This test measures batch read operations per second.

Test Name

No Load (events/sec)

500 AVC events/sec

% Loss/Gain

1000 AVC events/sec

% Loss/Gain

Legacy Batch Read

116

110

5.5%

107

8.1%

Analysis:

  • Unlike search and write operations, legacy batch read performance improves under load, showing a 5.5% gain at 500 AVC events/sec and 8.1% gain at 1,000 AVC events/sec.

Conclusion & Recommendations

  • Performance Degradation Observed: Across all test cases, response times increase under load, with Trust Level Filter searches being the most affected.

  • Read vs. Write Operations: NCMP synchronous write operations degrade more than read operations under high load.

  • Batch Read Stability: While performance shows a slight gain under load, batch reads remain consistent and improve efficiency as the event rate increases.

Recommendations:

  1. Optimize Search Queries: Trust Level and CPS Path filters should be optimized to reduce processing time under high load.

  2. Parallel Processing for Write Operations: Implementing parallelism or batching for synchronous writes may reduce the observed degradation.

  • No labels