Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

IN PROGRESS

Table of Contents


Overview

Bulk Edit - Establish a performance baseline for user status bulk updates. 

  • How long does it take to export 100, 1000, 2500, 10k, and 100K records?
  • Use it for up to 5 concurrent users.  
  • Look for a memory trend and CPU usage


Infrastructure

PTF -environment

  • 9 m6i.2xlarge EC2 instances located in US West (Oregon)us-west-2 AWS region (comparing to 10 m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1 for Morning Glory release)
  • 2 instances of db.r6.xlarge database instances, one reader, and one writer
  • MSK ptf-kakfka-1
    • 4 m5.2xlarge brokers in 2 zones
    • Apache Kafka version 2.8.0

    • EBS storage volume per broker 300 GiB

    • auto.create.topics.enable=truec
    • log.retention.minutes=480
    • default.replication.factor=3

...

MG- Morning Glory release

Software Versions

  • mod-data-export-worker-1.5.0-SNAPSHOT.76
  • mod-data-export-spring-1.5.0-SNAPSHOT.58
  • mod-agreements-5.4.0-SNAPSHOT.104
  • mod-notes-4.0.0-SNAPSHOT.237
  • mod-users-19.0.0-SNAPSHOT.573
  • mod-inventory-19.0.0-SNAPSHOT.383
  • mod-inventory-storage-25.0.0-SNAPSHOT.631
  • okapi-4.14.4

Summary 

Test report for Bulk Edits items-app functionality 2022-10-27. 

  • 10k records per user, 5 users simultaneously (50k records total) can be uploaded in about 10 min 45 seconds, and edited in 17 minutes (about 28 min total).
  • The files with identifiers should be strictly determined.
  • The memory of mod-data-export-worker increased from 88% at the start of the tests and was about 102% at the end. Each step of memory increase is related to CPU spikes at the beginning of the records update. mod-inventory-storage memory increased from 80% to 94% (the possible reason is stepped increasing while another process starts on the server (indexing and EDIFACT)). mod-inventory memory increased by 2% (from 60% to 62% and become stable) after 2 of 3 50k records updating jobs were finished and only 1 job remaining. All other modules' memory usage was stable.
  • CPU - for 5 parallel jobs - for mod-data-export-worker are spiking up to 120% at the start of records updating( in general usage was about 8%). For all other modules did not exceed 40%.
  • For all records number (100, 1k,10k, 25k, 50k), 5 concurrent jobs - RDS CPU utilization did not exceed 32%.

Results

Test Runs

Items App - updating item status

Record identifier files location - http://carrier-io.int.folio.ebsco.com/artifacts?q=export

5 concurrent jobsNolanaMorning Glory

"BARCODE". Records number per 1 user

Time to uploadTime of POST /bulk-edit/${jobId}/uploadTime to edit - commit changesTotal timeTime to upload

Time of POST /bulk-edit/${jobId}/upload

Time to edit - commit changesTotal time
1006 8 sec2 sec10 sec18 sec10-12 sec2 sec12-13 sec25-27 sec
10001 min 30 10 sec24-30 sec1 min 25 sec3 min 20 sec1min 40 sec2-10 sec2 min 15 sec4 min
10k10 min 45 sec6-7 sec16-17min28 min11 min 05 sec2-3 sec17-21 min30 min
25k28 min20 sec35 min1 hour 3 min21 min6 sec29-30 min50 min
50k

3 of 5 successful - 56 min (files have 50k matched records)

2 of 5 failed "Connection reset (SocketException)"

41 sec

1 job- 50k records were processed in 44 min ({
  "total": 50000,
  "errors": 21543,
  "success": 28457,
  "progress": 100,
  "processed": 50000
})UPDATED and Errors files generated successfully.

For 2 of 3 jobs only 25k records were updated (UPDATED files have 25k records {
  "total": 25000,
  "errors": 0,
  "success": 25000,
  "progress": 100,
  "processed": 25000
} but Matched records files after identifiers uploaded - have 50k records)

about 2 hours for successful jobs."Connection reset (SocketException)"---

 * "-" test was not performed due to errors that occurred

Memory usage

The memory of mod-data-export-worker increased from 88% at the start of the tests and was about 102% at the end. Each step of memory increase is related to CPU spikes at the beginning of the records update. mod-inventory-storage memory increased from 80% to 94% (the possible reason is stepped increasing while another process starts on the server (indexing and EDIFACT)). mod-inventory memory increased by 2% (from 60% to 62% and become stable) after 2 of 3 50k records updating jobs were finished and only 1 job remaining. All other modules' memory usage was stable.


CPU utilization

      CPU - for 5 parallel jobs - for mod-data-export-worker are spiking up to 120% at the start of records updating general usage was about 8%. For all other modules did not exceed 40%.


RDS CPU utilization

For all records number (100, 1k,10k, 25k, 50k), 5 concurrent jobs - RDS CPU utilization did not exceed 32%.

...