| Table of Contents |
|---|
Overview
Per PERF-267, test EDIFACT PERF-270 exports of 10K records to understand the workflow behavior before and when the mod-data-export-worker task crashes, if it crashes at all.
- How long does it take to export 10K records?
- What What happens to the job that is running, will it be able to resume and complete successfully when the new task is spun up?
- Look for a memory trend and use it to decide on the number of concurrent jobs needed to reach the tipping point.
Infrastructure
- 10 m6i.2xlarge EC2 instances (changed. In Lotus it was m5.xlarge)
- 2 instances of db.r6.xlarge database instances, one reader and one writer
- MSK. (topics being used [cluster].[tenant].data-export.job.command , [cluster].[tenant].data-export.job.update)
- 4 m5.2xlarge brokers in 2 zones
- auto.create-topics.enable = true
- log.retention.minutes=120
- 2 partitions per DI topics
Software Versions
- mod-data-export-worker v 1.4.2
- mod-data-export-spring v 1.4.2
- mod-agreements:5.2.0
- mod-notes:3.1.0
- mod-orders-storage:13.3.0
- mod-orders:12.4.1
Results
Summary
| job Num | Number of records | Duration |
|---|---|---|
000257 | 1k | 1 min 52 s |
000258 | 2k | 3 min 33 s |
000259 | 5k | 8 min 50 s |
000260 | 10k | 17 min 4 s |
- All resources shows predictable behaviour without gaps and sudden spikes.
- Memory usage growing on mod-orders (48%-56%) and mod-orders-storage (45%-51%). However it doesn’t looks like memory leak as it didn't grow continuously. It just grows at the beginning of subsequent exports.
Knowing Known issue:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Resources usage
Endurance test
Below charts represents that system is working stable.
For the endurance testing scheduler this particular test scheduler inside one organisation integration was set to occur hourly over nightand left overnight, export performed at least 19 times.
This organisation has 10k orders to export.
As you can see there is no growing of memory usage
...