| 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 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 |
...
Known issue:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Resources usage
Endurance test
Below charts represents that system is working stable.
...