Overview

• Currently FSE's hosting of FOLIO consists of running ECS tasks (module docker containers) over 10-14 ec2 m6g.2xlarge instances.  We'd like to experiment with a different types of ec2 instance, x2gd, and with different numbers of ec2 instances to see if the performance is comparable to the baseline. Also, we'd like to understand the true CPU usage of the modules by setting setting CPU (units) in the modules' task definitions to 0.  To do this we ran the MOBIUS (multi-workflows, multi-tenants) tests on the mcpt environment with different environment configurations and compare the test results to the baseline's report. This report contains the test results of these experiments. 

PERF-942 - Getting issue details... STATUS  

Summary

• Much performance degradation when we use less instance count for environment or instance type: .x2gd.large with less resources.
• During the tests Parameter CPU=0 improved performance for a several workflows, so this point we are going to investigate more in this ticket.

• No memory leaks, memory consumption was stable during all of the tests.

• Tests had 100% errors count for AIE_TC: Create Invoices, AIE_TC: Invoices Approve, AIE_TC: Paying Invoices, TC: Receiving-an-Order-Line, Unreceiving-a-Piece and Unreceiving-a-Piece Workflows because data was not regenerated.  

Test Runs and Results

This table contains durations for all Workflows. 

Comparison

This graph shows the total durations of all workflows compared between tests.

Service CPU Utilization

Here we can see that CPU did not exceed 95% of the unit CPU power for all of the modules.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Kafka metrics

DB CPU Utilization

DB CPU was 99% average with ERW: Exporting Receiving Information

DB Connections

Max number of DB connections was 5568 in maximum.

Service CPU Utilization

Here we can see that okapi used 13% of the absolute CPU power of the container instance.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Kafka metrics

DB CPU Utilization

DB CPU was 99% average with ERW: Exporting Receiving Information

DB Connections

Max number of DB connections was 5788.

DB load

Top SQL-queries

Service CPU Utilization

Here we can see that mod-permissions used 20% of the absolute CPU power of the container instance.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Kafka metrics

DB CPU Utilization

DB CPU was 64% maximum.

DB Connections

Max number of DB connections was 2040.

Service CPU Utilization

Here we can see that okapi used 20% of the absolute CPU power of the container instance.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Instance CPU Utilization

Kafka metrics

DB CPU Utilization

DB CPU was 91%.

DB Connections

Max number of DB connections was 4840.

DB load

Top SQL-queries

Service CPU Utilization

Here we can see that okapi used 36% of the absolute CPU power of the container instance.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Instance CPU Utilization

Kafka metrics

DB CPU Utilization

DB CPU was 42%.

DB Connections

Max number of DB connections was 3650.

DB load

Top SQL-queries

Service CPU Utilization

Here we can see that okapi used 46000% CPU of unit power.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Instance CPU Utilization

Kafka metrics

DB CPU Utilization

DB CPU was 98%.

DB Connections

Max number of DB connections was 5150.

DB load

Top SQL-queries

Instance CPU Utilization

Kafka metrics

DB CPU Utilization

DB CPU was 98%.

DB Connections

Max number of DB connections was 5150.

DB load

                                                                                                                     

Top SQL-queries

Test №8

Introduction:TheBaseline MCPT Environment configurationwas applied, theinstance typewas changed tox2gd.large, thenumber of instanceswas changed to14, placement strategy was updated to"one task per host",andCPU=2was set for allservices.

Objective: The objective of this test is to evaluate the performance and behavior of the MCPT environment using the x2gd.large instance type with a consistent number of instances (14) and the "one task per host" placement strategy. By setting CPU=2 for all services, we aim to assess the impact of these configurations on overall system performance, responsiveness, and stability, and to compare the results with previous tests to determine the effectiveness of the new setup.

Results: The test revealed a significant performance degradation, with the total average duration for all workflows being approximately 5 times worse compared to the Baseline Test №1. Additionally, there was an imbalance in CPU utilization across instances, indicating that some instances were underutilized while others were overloaded.

Service CPU Utilization

Here we can see that okapi used 38% of the unit CPU power.

Service Memory Utilization

Here we can't see any sign of memory leaks on every module. Memory shows stable trend.

Instance CPU Utilization

Appendix

Infrastructure

PTF - Baseline MCPT environment configuration

• 14 m6g.2xlarge EC2 instances located in US East (N. Virginia)us-east-1

• 1 database  instance, writer

  Name	Memory GIB	vCPUs
  db.r6g.4xlarge	128 GiB	16 vCPUs

• Open Search ptf-test 
  • Data nodes
    • Instance type - r6g.2xlarge.search
    • Number of nodes - 4
    • Version: OpenSearch_2_7_R20240502
  • Dedicated master nodes
    • Instance type - r6g.large.search
    • Number of nodes - 3
  • MSK ptf-KRaft-mode
    
    • 2 brokers, kafka.m7g.xlarge brokers in 2 zones

    • Apache Kafka version 3.7.x 

    • EBS storage volume per broker 300 GiB

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

Methodology/Approach

MOBIUS Tests: scenarios were started by JMeter script from load generator. We had 100% error count for AIE_TC: Create Invoices, AIE_TC: Invoices Approve, AIE_TC: Paying Invoices, TC: Receiving-an-Order-Line, Unreceiving-a-Piece and Unreceiving-a-Piece Workflows because data was not regenerated.  

• Test 1: Baseline MCPT Environment configuration according to tunning environment from previous report:  task count: 4 for services: mod-permissions, mod-search, mod-patron, mod-inventory, mod-inventory-storage, mod-circulation, mod-circulation-storage, mod-order, mod-order-storage, mod-invoice, mod-invoice-storage, for mod-users and mod-authtoken task count 6. Parameter srs.marcIndexers.delete.interval.seconds=86400 for mod-source-record-storage. Instance type: m6g.2xlarge. Instances count: 14. Database r6g.4xlarge, Amazon OpenSearch Service  ptf-test: r6g.2хlarge.search (4 nodes).
• Test 2: The Baseline MCPT Environment configuration was applied, and CPU=0 was set for all modules.
• Test 3: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.xlarge, the number of instances was changed to 6, and CPU=0 was set for all services.
• Test 4: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.xlarge, the number of instances was changed to 8, and CPU=0 was set for all services.
• Test 5: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.large, the number of instances was changed to 10, and CPU=0 was set for all services.
• Test 6: The Baseline MCPT Environment configuration was applied, the instance type was changed to r6g.xlarge, the number of instances was changed to 14 but 12 were used, and CPU=2 was set for all services.
• Test 7: The Baseline MCPT Environment configuration was applied, the instance type was changed to r6g.xlarge, the number of instances was changed to 14, placement strategy was updated to "one task per host", and CPU=2 was set for all services.
• Test 8: The Baseline MCPT Environment configuration was applied, the instance type was changed to x2gd.large, the number of instances was changed to 14, placement strategy was updated to "one task per host", and CPU=2 was set for all services.