/
CPS-2691 Performance Improvements DCM Write Job Analysis

CPS-2691 Performance Improvements DCM Write Job Analysis

References

  1. https://lf-onap.atlassian.net/browse/CPS-2691

  2. https://lf-onap.atlassian.net/browse/CPS-2692

  3. Performance Test Commit

WriteDataJob Performance Test Report

Overview

This report presents the performance test results for the writeDataJob method in DataJobService. The test dynamically generates write operations and measures execution time to assess the efficiency of the method.

Test Setup

Test Environment

  • Test Class: WriteDataJobPerfTest

  • Service Under Test: DataJobService.writeDataJob

  • Test Framework: Spock (Groovy-based testing framework)

  • Infrastructure:

    • CM Handles: 1,000 registered with alternative IDs

    • Write Operations per Test Run: 1,000 (each containing 3 sub-operations)

Methodology

  1. CM Handles Registration: A sequence of 1,000 CM handles was registered.

  2. Data Job Request Generation: populateDataJobWriteRequests method dynamically created write operations.

  3. Write Job Execution: The writeDataJob method was invoked with dynamically generated requests.

  4. Performance Measurement: ResourceMeter recorded execution time.

  5. Cleanup: CM handles were deregistered post-execution.

Test Results

Test Run

Execution Time (seconds)

Test Run

Execution Time (seconds)

1

30

2

36

3

40

4

26

5

43

Avg.

35

Average Execution Time

The average execution time across all test runs:

Average Execution Time: 38 seconds

Observations

  • Execution time ranged between 26 seconds and 43 seconds.

  • The average execution time was 38 seconds.

  • The performance remained consistent across multiple runs.

  • The slight variation in execution time could be due to runtime factors such as system load and resource availability.

Test Results (After Code Change 140455: Batch Fetch All CM-Handles for Faster Data Job)

Execution Time per Test Run

Test Run

Execution Time (seconds)

1

0.818

2

1.184

3

0.746

4

0.807

5

0.840

Avg.

0.879

Average Execution Time

  • Average Execution Time: ~0.88 seconds

  • Execution Time Range: 0.745 to 1.184 seconds

Observations

  • Significant performance improvement observed after applying the code change.

  • The new approach of batch fetching CM-handles reduced execution time drastically.

  • Execution time is now in the sub-second range, showing optimized performance.

Conclusion

The writeDataJob method exhibited a dramatic improvement in performance after implementing batch fetching of CM-handles. Execution time reduced from an average of 38 seconds to approximately 0.88 seconds, demonstrating the effectiveness of the optimization. Further tests under varied conditions may be conducted for deeper insights into system behavior under different loads.

Parallel Execution Performance Analysis (CPS-2692)

Test Setup

  • Number of Parallel Threads: 10

  • Number of CM Handles Registered: 10,000

  • Write Operations per Job: 1,000

  • Total Write Operations: 10,000 (distributed across 10 jobs)

  • Concurrency Mechanism: ExecutorService with CompletableFuture.supplyAsync()

Test Results (Parallel Execution)

Execution Time (seconds)

Memory Usage (MB)

Execution Time (seconds)

Memory Usage (MB)

1

2.04

114.7

2

2.05

114.7

3

2.05

114.7

4

2.04

114.7

5

2.03

114.7

6

2.04

114.7

7

2.06

118.8

8

2.04

114.7

9

2.04

118.8

10

2.05

114.7

11

2.05

115.5

Key Observations

  1. Execution Time Consistency

    • All jobs completed in approximately 2.03 - 2.06 seconds, demonstrating stable execution under parallel processing.

    • Low variance in execution time suggests that parallelism was well-distributed across threads without significant contention.

  2. Memory Usage Consistency

    • all executions required around 115MB due to loading the entire cm-handle map to translate (a few) cm handles. Given the requirements of max 10 threads and total memory of 2GB this is just about acceptable.

    • Note. The amount of memory used is NOT related to the amount of cm handles in the job as in any case all cm handles with be loaded into memory. The only thing that will differ is how long the memory is held on to i.e. while it iterates over the cm handles in the job

  3. Overall Performance Improvement

    • Compared to single-threaded execution (avg. 0.88 seconds), parallel execution keeps execution time within a predictable range per job (~2s each), ensuring stable performance for large-scale writes.

Comparative Analysis: Single-Threaded vs. Multi-Threaded Execution

Execution Mode

Avg. Execution Time (seconds)

Total Memory Usage (MB)

Execution Mode

Avg. Execution Time (seconds)

Total Memory Usage (MB)

Single-Threaded (Batch Fetching, CPS-2692)

~0.88

88.71 MB

Multi-Threaded (10 Jobs, CPS-2691)

~2.04 per job

~115 MB per job

Interpretation

  • Single-threaded execution is highly optimized, but multi-threaded execution scales predictably, maintaining stable memory and execution times.

  • Parallel execution does not introduce major performance bottlenecks, confirming that batch fetching supports multi-threaded workloads efficiently.

Conclusion

  • The writeDataJob method performs well under parallel execution.

  • Execution times remain stable (~2s per job) with predictable memory usage.