...
...
...
...
Overview
This document contains the results of testing List App refreshing of 200k records on multiple tenants with R/W split enabled (Poppy release). The goal of testing is to assess the performance of mod-lists with load spread across multiple tenants.
Ticket:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Summary
- ListApp refreshing duration is about 8.5 min when testing separately from other workflows. With Data Import and Check-in/Check-out scenarios added ListApp duration has +108% increase and reaches 17.7 min. It's above the expected value of 10 minutes.
- Data Import and Check-in/Check-out response times have increase about 10-20% with ListApp scenario added.
- According to the results, maximum CPU utilization for DI + CICO test is about 85%, while with ListApp scenario added CPU reaches 160%.
- RDS CPU utilizatoin is about 95% for DI+CICO test and it doesn't increase with ListApp scenario added.
Test runs
Query used in lists - "Item status != Available". List refresh result is about 200K records.
Scenario | Data quantity |
|---|---|
| List App 3 users refresh | tenant 1 - 1 user tenant 2 - 1 user tenants 3 - 1 user |
| List App 10 users refresh | tenant 1 - 3 user tenant 2 - 3 user tenants 3 - 4 user |
| List App 30 users refresh | tenant 1 - 10 user tenant 2 - 10 user tenants 3 - 10 user |
Results
| Transaction | Single tenant | 3 tenants | ||||
|---|---|---|---|---|---|---|
[Orchid] 10 users | [Poppy] 10 users | [Poppy] 10 users Testing in parallel with DI and CICO | [Poppy] R/W split enabled 3 users | [Poppy] R/W split enabled 10 users | [Poppy] R/W split enabled 30 users | |
| ListApp refresh, avg | from 9 min 40 sec to 10 min 40 sec | 8.5 min | 17.7 min | 1.5 min | 2.3 min | Internal servel error |