| Table of Contents |
|---|
This document contains the results of testing List Lists App refreshing multiple concurrent lists of 200k records on single tenant with R/W split enabled (Poppy release). The goal of testing is to assess the performance of the Lists App modules (mod-lists, mod-fqm-manager) with load spread from across multiple tenantsusers.
Ticket:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
- Load tests showed that single tenant ListApp refreshing refresh duration is:
- 2.6 min for 1 user refresh test;
- 3.1 min for 3 user testconcurrent refresh tests;
- 4.2 min for 5 user testconcurrent refresh tests;
- 6.5 min for 10 user testconcurrent refresh tests.
- Duration is below the maximum accepted value of 10 minutes.
- Tests showed that ListApp refreshing duration increases 2-3 times when conducted with the same user number but on 1 tenant instead of 3 tenants. For example, during 3 users test duration increased from 1.5 min to 3.1 min, for 10 users - from 2.3 min to 6.5 minload (number of concurrent lists refreshes) on three tenants performs better than on one tenant. For example on one tenant, 3-concurrent list refreshes took 3.1 minutes on average, but on 3 tenants only 1.5 minutes. On one tenant 10 concurrent lists-refreshes took 6.5 minutes on average, but the same load on 3 tenants averaged 2.3 minutes.
- During the 10 users lists refresh test CPU utilization reached 89% for mod-fqm-manager and 101% for mod-lists. In comparison with multiple tenants testing, CPU utilization for mod-fqm-manager is about 2 times lower for a single tenant test.
- Maximum DB CPU utilization reached 63% (writer instance) and 99% (reader instance) during 10 user lists-refresh test. In comparison with multiple tenants testing, RDS CPU utilization for writer instance is 20% lower for single tenant test.
- No memory leak is suspected for all the modules.
...
Scenario | Data quantity |
|---|---|
List App refresh single tenant | 1 userlist |
| 3 usersconcurrent lists | |
| 5 usersconcurrent lists | |
| 10 usersconcurrent lists |
Results
| ListApp Lists App refresh , avg | 1 userlist | 3 userslists | 5 userslists | 10 userslists |
|---|---|---|---|---|
| Poppy, single tenant, R/W split enabled | 2.6 min | 3.1 min | 4.2 min | 6.5 min |
| Poppy, multiple tenants, R/W split enabled* | 1.5 min | 2.3 min | ||
| Poppy, multiple tenants, R/W split disabled** | 1.9 min | 3.4 min |
*Results are taken from previous test report: [Poppy] List App with multiple tenants and R/W split enabled
**Results are taken from previous test report: [Poppy] List App with multiple tenants and R/W split disabled
Service CPU Utilization
During the 10 users lists refreshes test CPU utilization reached 89% for mod-fqm-manager and 101% for mod-lists.
...
Maximum DB CPU utilization reached 63% (writer instance) and 99% (reader instance) during 10 user lists test.
In comparison with multiple tenants testing, RDS CPU utilization for writer instance is 20% lower for single tenant test.
...
Infrastructure
PTF -environment pcp1
- 10 m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1
1 database instance, writer
Name API Name Memory GIB vCPUs max_connections R6G Extra Large db.r6g.xlarge 32 GiB 4 vCPUs 2731 - MSK tenant
- 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
...
- Enable R/W split for mod-fqm-manager.
- Create 10 lists with the query "Item status != Available" on each of three tenants to be able to run a test for up to 30 concurrent users.
- Prepare 200K item records for the query to return. Details can be found at the link: Steps for testing process#ListApp
- Conduct tests with JMeter script (single tenant).