Overview
This document contains the results of testing List App refreshing of 200k records in the Orchid release. - PERF-619Getting issue details... STATUS
Summary
- Duration for list refresh of 200k records is up to 11 minutes 40 seconds for 10 concurrent users.
- Memory utilization increasing for mod-lists up to 33% due to previous module restarting and everyday cluster shutdown processes - no memory leak is suspected for all of the modules.
- For mod-lists, CPU utilization was up to 384% for the test with 10 concurrent users and R/W split disabled. Average CPU usage did not exceed 13 % for all other modules.
- Approximately DB CPU usage is up to 99.5%.
Recommendations and Jiras
Use database read-write split enabled for mod-lists to improve performance.
Results
200k records list refresh for each user.
Number of users | Duration Test 1 | Duration Test 2 | Duration Test 3 |
---|---|---|---|
mod-lists R/W split enabled | |||
1 user | 13 min 30 sec (1st time after mod-lists restart) | 4min 33 sec | 4 min 52 sec |
2 users | 4 min 40 sec | 5 min | 4 min 55 sec |
5 users | 6 min-6 min 13 sec | 6 min 16 sec-6 min 24 sec | 6min 41 sec |
10 users | 9 min 40 sec - 10 min 10 sec | 10 min -10 min 40 sec | 9 min 50 sec-10 min 7 sec |
mod-lists R/W split disabled | |||
1 user | 13 min 23 sec (1st time after mod-lists restart) | 4 min 30 sec | 4 min 24 sec |
2 users | 4 min 42 sec | 5 min 15 sec | 5 min 19 sec |
5 users | 7 min -7 min 29 sec | 6 min 55 sec- 7 min 24 sec | 7 min -7 min 25 sec |
10 users | 10 min 30 sec - 11 min 35 sec | 11 min 10 sec- 11 min 40 sec | 10 min 45 sec- 11 min 35 sec |
mod-lists R/W split disabled + increased CPU to 512 for mod-lists | |||
1 user | 5 min 3 sec (1st time after mod-lists restart) | 4 min 55 sec | 5 min |
2 users | 5 min | 5 min 42 sec | 5 min 25 sec |
5 users | 7 min 30 sec- 8 min | 7 min 10 sec- 7 min 30 sec | 7 min 10 sec- 7 min 30 sec |
10 users | 10 min -10 min 45 sec | 10 min 10 sec -11 min | 10 min 45 sec- 10 min 55 sec |
* - Tests were performed with disabled circulation jobs
Memory Utilization
Memory utilization increasing for mod-lists up to 33% due to previous module restarting and everyday cluster shutdown processes - no memory leak is suspected for all of the modules.
mod-lists
Service CPU Utilization
For mod-lists, CPU utilization was up to 384% for the test with 10 concurrent users and R/W split disabled. Average CPU usage did not exceed 13 % for all other modules. Each CPU spike corresponds to a separate list refresh.
RDS CPU Utilization
RDS CPU Utilization was very high. Approximately DB CPU usage is up to 99.5%
RDS Database Connections
DB Load
Long-running queries:
select id from [tenant]_mod_fqm_manager.drv_item_details where lower(cast(item_status as varchar)) = lower($1) order by item_effective_call_number asc, item_effective_location_name asc, instance_title asc, instance_primary_contributor asc
delete from list_contents where list_id=$1 and refresh_id=$2
Appendix
Infrastructure
Records count :
- mod_inventory_storage.item = 22130108
PTF -environment ncp5
- 12 m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1
2 database instances, one reader, and one writer
Name API Name Memory GIB vCPUs max_connections R6G Extra Large db.r6g.xlarge 32 GiB 4 vCPUs 2731 - 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=true
- log.retention.minutes=480
- default.replication.factor=3
Modules memory and CPU parameters
Methodology/Approach
To test Baseline for List refresh JMeter scripts were used.
Test preparation:
- Background circulation jobs were disabled.
- 200k items were checked out
- 10 lists were created with the query: (item_status == "Checked out") to be able to run a test for 10 concurrent users.
Refresh list for 1, 2, 5, and 10 concurrent users tested