CM Data Performance Test Results

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 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 1,000 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.

  View file
  name CPS-2587-CM Data Performance Test Results.ods

Results Summary

CM-Handle ID Search Performance

...

...

...

...

Analysis:

• Unlike search and write operations, legacy Legacy batch read performance improves declines under load, showing with a 5.5% gain decrease at 500 AVC events/sec and an 8.1% gain decrease at 1,000 AVC events/sec. This indicates that as the system experiences more AVC events, the efficiency of batch read operations is negatively impacted. The increasing loss suggests that higher event rates introduce processing overhead, potentially due to resource contention, increased latency, or queuing delays. These factors may contribute to slower response times and reduced throughput for batch read operations under heavy system load.

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.

Overall Performance Impact:

• The average performance loss at 500 AVC events/sec is -5.9%.

• The average performance loss at 1,000 AVC events/sec is -11.5%.

This indicates a gradual performance degradation as the event rate increases, emphasizing the need for optimization in high-load scenarios.

Possible Bottlenecks

• Kafka partitioning

  • using a single Kafka partition can significantly affect event processing, especially under high load. Here’s how it impacts performance:

Impact of Single Kafka Partition on Event Processing:

1. Throughput Bottleneck:

   • Kafka distributes messages across partitions, allowing multiple consumers to process data in parallel.

   • With only one partition, all events are handled by a single consumer, limiting the processing speed.

2. Increased Latency:

   • Since there is no parallelism, events are processed sequentially rather than concurrently.

   • As load increases (e.g., 500 or 1000 AVC events/sec), processing delays may accumulate, causing performance degradation.

3. Consumer Scaling Limitation:

   • Kafka allows multiple consumers within a consumer group to read from different partitions.

   • With a single partition, adding more consumers will not improve performance since only one consumer can read from it at a time.

Recommendations to Improve Performance:

✅ Increase the Number of Partitions

• Use multiple partitions to enable parallel processing and higher throughput.

• A good rule of thumb: Number of partitions = Number of consumers × Desired parallelism level.

✅ Tune Consumer Configuration

• Increase fetch.max.bytes, max.poll.records, and optimize commit.interval.ms for better performance.

Conclusion:

Yes, using a single Kafka partition is likely affecting event processing, especially under high event rates (500 or 1,000 AVC events/sec). Scaling partitions and optimizing consumer settings can help mitigate performance issues. 🚀

Notes: How to check kafka configuration of CPS ?

Checking in Kafka Configuration (For Default Settings)

If you haven't explicitly set the number of partitions while creating the topic, Kafka may use the default partition count from the broker settings.

To check Kafka's default number of partitions, run:

cat /etc/kafka/server.properties | grep num.partitions

Example Output:

num.partitions=1

num.partitions=1

• If it's 1, all newly created topics will have a single partition by default unless overridden.

• This image confirms that Kafka is configured with a single partition (num.partitions=1) into CPS.

...