Check-in by users with 10 TLR each (Nolana) - deprecated

This page is deprecated, please see the actual report here: [Nolana] Check-IN + title-level requests

Overview

Test goal is to assess performance of circulation check-in functionality for users with 10 TLR (title-level requests) each.

Ticket: PERF-350 - Getting issue details... STATUS


Summary

Load tests showed that there is no significant difference in performance of users with TLRs and without it.

Test Runs 

Test #

Test Conditions

Duration 

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

Notes


1.

Checkin with 1, 8, 20 users

30 mint3.medium3

ncp3 environment


Results

Response Times

Baseline (users without TLR)


Verification (users with 10 TLRs)

Response time comparison


Users quantity

Response time 95prc, sec


Degradation, sec


Degradation, %

Baseline

(users without TLR)

Verification

(users with 10 TLR each)

1 user0.8380.742-0.096-11%
8 users0.5380.5550.0173%
20 users0.4950.5310.0367%

Instance CPU Utilization

Baseline (users without TLR)


Verification (users with 10 TLRs)


Service CPU Utilization

Baseline (users without TLR)


Verification (users with 10 TLRs)

Memory Utilization

Baseline (users without TLR)


Verification (users with 10 TLRs)

RDS CPU Utilization

Baseline (users without TLR)

There are several spikes during test with 1 user load. This can be caused by background jobs, as such behaviour wasn't reproduced during other tests.


Verification (users with 10 TLRs)

RDS DB connections

Baseline (users without TLR)


Verification (users with 10 TLRs)


Database Load

Baseline (users without TLR)


Verification (users with 10 TLRs)

Appendix

Infrastructure

PTF -environment ncp3

  • 10 m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1
  • 2 instances of db.r6.xlarge database instances: Writer & reader instances
  • MSK ptf-kakfa-3 [ kafka configurations]
    • 4 kafka.m5.2xlarge brokers in 2 zones
    • Apache Kafka version 2.8.0

    • EBS storage volume per broker 300 GiB

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


Modules memory and CPU parameters:

Modules

Version

Task Definition

Running Tasks 

CPU

Memory (Soft/Hard limits)

MaxMetaspaceSize

Xmx

okapi4.14.7131024

1440/1684

512922
mod-feesfines18.1.132128896/1024128768
mod-patron-blocks1.7.1421024896/1024128768
mod-pubsub2.7.0421024

1440/1536

512922
mod-authtoken2.12.032

512

1152/1440

128

922

mod-circulation-storage15.0.2321024

1440/1536

512896
mod-circulation23.3.2321024896/1024128768
mod-configuration5.9.032128896/1024128768
mod-users19.0.042128896/1024128768
mod-remote-storage1.7.1321281692/18725121178


Methodology/Approach

  1. Conduct necessary commands to return the database to the initial state. Do this before each test run. Wait several minutes before the test start.
  2. Conduct check-in load tests with different number of users.
  3. Repeat tests with the same approach but before each test also generate 10 TLR for each user by running JMeter script (Create_TLR.jmx).
  4. Compare test results.

Grafana dashboard

Baseline (users without TLR): http://carrier-io.int.folio.ebsco.com/grafana/d/elIt9zCnz/jmeter-performance-test-copy?orgId=1&var-percentile=95&var-test_type=baseline&var-test=circulation_checkIn_nolana2&var-env=int&var-grouping=1s&var-low_limit=250&var-high_limit=750&var-db_name=jmeter&var-sampler_type=All&from=1675246584127&to=1675253996913

Verification (users with 10 TLRs): http://carrier-io.int.folio.ebsco.com/grafana/d/elIt9zCn