Skip to end of banner
Go to start of banner

Combined Bulk edit + Check-in-check-out + Data Import (Nolana) 28-12-2022

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

20-users testsAvgMax

mod-users21%21%

mod-pubsub5%5%

okapi14%14%

mod-circulation4%4%

mod-circulation-storage5%5%

mod-inventory7%7%

mod-inventory-storage7%7%

mod-patron-blocks1%1%

mod-feesfines17%17%

mod-authtoken31%20-users testsAvgMax


mod-users21%21%


mod-pubsub5%5%


okapi14%14%


mod-circulation4%4%


mod-circulation-storage5%5%


mod-inventory7%7%


mod-inventory-storage7%7%


mod-patron-blocks1%1%


mod-feesfines17%17%


mod-authtoken31%78%










Overview

This is a report for a series of Check-in-check-out test runs together with Bulk edits + Data Import in the Nolana release to see how these workflow interact with one another, especially because they all use mod-inventory.

Infrastructure

PTF -environment ncp3

  • 10 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-kakfa-3
    • 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

Modules memory and CPU parameters

Modules

Version

Task Definition

Running Tasks 

CPU

Memory

MemoryReservation

MaxMetaspaceSize

Xmx

mod-authtoken2.12.012

512

(128 in MG)

1440

(1024 in MG)

1152

(896 in MG)

128

922

(768 in MG)

mod-circulation23.3.01210241024896128768
mod-circulation-storage15.0.0121024

1536

(1152 in MG)

1440

(1024 in MG)

512896
mod-configuration5.9.0121281024896128m768m
mod-data-import2.6.11125620481844512m1292m
mod-data-import-cs1.15.1122581024896128m768m
mod-feesfines18.1.0121281024896128768
mod-inventory19.0.112102428802592512m1814m

mod-inventory-storage

25.0.1121024

2208

(1872 in MG)

1952

(1684 in MG)

512m1440m
mod-patron-blocks1.7.11210241024896128768
mod-pubsub2.7.0121024

1536

(1440 in MG)

1440

(1296 in MG)

512922
mod-quick-marc2.5.011128

2288

(2098 in MG)

2176

(1920 in MG)

512m1664m
mod-remote-storage1.7.01212818721684512m1178m
mod-source-record-manager3.5.4221024

4096

(2048 in MG)

3688

(1844 in MG)

512m

(800M in MG)

2048m

(1024m in MG)

mod-source-record-storage5.5.2121024

1536

(1440 in MG)

1440

(1296 in MG)

512m908m
mod-users19.0.0122581024896128m768m
okapi4.14.7131024

1684

(1512 in MG)

1440

(1360 in MG)

512m922m
mod-data-export-worker2.0.362102430722600512

2048

(1536 in MG)

mod-data-export-spring1.5.02125620481844512

1536

(1236 in MG)

mod-notes4.0.0121281024896128m

768m

mod-agreements5.4.01212815921488512m968m

MG- Morning Glory release

Front End:

  • Item Check-in (folio_checkin-7.2.0)
  • Item Check-out (folio_checkout-8.2.0)


High-Level Summary

  • In general, response times for CI/CO are consistently good, even better than the CI/CO + DI test without bulk editing. We can observe a decrease in response time spikes number which can cause better results.
  • Compared to baseline DI time increases for updates (baseline 24 min 5 s compared to test #4 and Test #3 about 30 min). Bulk edit time increases for tests with DI Create (about 10 min slower).
  • No errors or issues were found during the run of 3 workflows (Check-in/Check-out 8 users + Data Import MARC BIB 50k.mrc + Bulk edit 10k Items or 10k Holdings records)
  • Memory usage is stable for all modules, except for mod-source-record-manager, ​ mod-source-record-storage, and mod-inventory increased (reason: modules were restarted manually before the tests. No memory leaks were found during modules memory leaks investigation
    Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    ). 
  • For all services CPU usage did not exceed 130% for tests 1 and 2 and did not exceed 170% for tests 3 and 4.
  • RDS CPU usage was high up to 94%

Test Runs

Test

Virtual Users

Duration of CI/CO

Load generator size (recommended)Load generator Memory(GiB) (recommended)

1.

8 users CI/CO + DI 50k MARC BIB Create+ 10k Items editing30 minst3.medium3

2.

8 users CI/CO + DI 50k MARC BIB Create+ 10k holdings editing30 minst3.medium3

3.

8 users CI/CO + DI 50k MARC BIB Update+ 10k Items editing30 minst3.medium3
4.8 users CI/CO + DI 50k MARC BIB Update+ 10k Holdings editing30 minst3.medium3

Results

Response Times (Average of all tests listed above, in seconds)


Check-in-check-outBulk editData Import

Average (seconds)ItemsHoldingsMARC BIB

Check-inCheck-out10k records10k records50k Create50k Update
Test 10.7151.33240 min-20 min 19 sec-
Test 20.7561.383-20 min 30 sec21min  07 sec-
Test 30.5671.02932 min--33 min 33 sec
Test 40.5520.987-9min 20 sec-30 min 52 sec
Jobs Baseline time to compare (single process)0.4560.69828 min12 min 25 sec23 min 43 s24 min 5 s
CICO + DI MARC BIB Create time 0.9261.666--19min 28s-
CICO + DI MARC BIB Update time 0.7001.199---27min 39s
CICO + Holdings Bulk Edit time0.4280.790-11 min 20 sec--
CICO + Items Bulk Edit time0.4310.79320min *---

* - Before the Combined Bulk edit + Check-in-check-out + Data Import test, the Items Bulk edit scenario was changed to the latest requirements so the duration for bulk edits could differ.

Response times for CI/CO are consistently good, even better than the CI/CO + DI test without bulk editing. We can observe a decrease in response time spikes number which can cause better results.

Compared to baseline DI time increases for updates (baseline 24 min 5 s compared to test #4 and Test #3 about 30 min). Bulk edit time increases for tests with DI Create (about 10 min slower).

Memory Utilization

  • Memory usage is stable for all modules, except for mod-source-record-manager, ​ mod-source-record-storage, and mod-inventory increased (reason: modules were restarted manually before the tests. No memory leaks were found during modules memory leaks investigation Unable to locate Jira server for this macro. It may be due to Application Link configuration. ). 



 Modules CPUs Utilization


Instance CPU Utilization 

Database and network

RDS CPU usage was high up to 94%

Memory & CPU Utilization table

Nolana

 CPU Avg

 Memory Max

mod-users19%27%
mod-pubsub4%32%
okapi40%45%
mod-circulation1%67%
mod-circulation-storage1.5%32%
mod-inventory165%66%
mod-inventory-storage35%43%
mod-patron-blocks0.5%34%
mod-feesfines5%28%
mod-authtoken10%16%
mod-data-import-cs130%27%
mod-quik-marc88%21%
nginx-okapi73%3%
mod-source-record-storage46%60%
mod-source-record-manager41%73%
mod-remote-storage29%29%
mod-configuration8%24%
mod-data-export-worker5%81%
mod-graphql3.5%46%
mod-data-import80% at the start23%
pub-okapi3%2.6%
mod-data-export-spring2%62%
mod-erm-usage-harvester3%31%

All other modules' CPU usage was less than 2%.

Data is from test #4



  • No labels