Overview
- In Quesnelia the profile page allows users to upload a profile picture and to view the page with the picture. The purpose of the ticket is to compare performance of Patron Profile Page with loading picture and without loading picture in scope of - PERF-790Getting issue details... STATUS ticket on PCP1 environment.
- Also in scope is checking how the volume of pictures as well as the images' storage choice, DB or S3 bucket affect loading time,
Summary
- Four tests were carried out to compare results with different ways to store pictures in User's profile. It was possible to enable/disable functionality, change source storage and maximum possible value of file size on the fly with API config requests.
- Profile Picture functionality does not affect Patron Page loading response times and it works even faster (60-140 ms, depends on the flow).
- After populating DB and S3 bucket with pictures (3 times more data) two tests were carried out to see how it affect Patron Page loading time.
- Volume of pictures in DB or S3 bucket does not affect response times during Patron Page loading.
Recommendations & Jiras
- It was difficult to update mod-user correctly during deploying. Please take a look into the process. It may skip profile_picture table creation or create with not correct number of columns for some reason. The functionality has dependency from mod-permission so the module version should correspond to latest with all needed UI permissions for admin user.
Test Runs
These baseline test results on mod-users 19.2.2 version without Profile Picture functionality before deploying the version which support profile picture functionality
Requests | Executions | Response Times (ms), Average |
---|---|---|
Label | #Samples | Disabled Profile Picture |
TC: Search User* | 10 | 44.5 |
TC: View User** | 10 | 1138.1 |
* - TC: Search User - GET request which search user by UUID
** - TC: View User - patron page loading for UUID from a previous GET request
This table shows tests of patron page loading with different configuration of source storage
Tests | Profile Picture Functionality | Source storage | Threads | Loops | File size |
---|---|---|---|---|---|
#1 | Disabled | 5 | 100 | ||
#2 | Enabled | DB | 5 | 100 | No pictures |
#3 | Enabled | DB | 5 | 100 | 3,7 Mb |
#4 | Enabled | S3 bucket | 5 | 100 | 3,7 Mb |
Tests after populating of DB and S3 bucket with pictures. The volume increased 3 times.
Tests | Profile Picture Functionality | Source storage | Threads | Loops | File size |
---|---|---|---|---|---|
#5 | Enabled | DB | 5 | 100 | 3,7 Mb |
#6 | Enabled | S3 bucket | 5 | 100 | 3,7 Mb |
Results
Compare results
Requests | Executions | Response Times (ms), Average | ||||||
---|---|---|---|---|---|---|---|---|
Label | #Samples | Baseline, mod-users 19.2.2 No Profile Picture functionality | Test #1 Disabled Profile Picture | Test #2 Enabled Profile Picture, DB | Test #3 Enabled Profile Picture, DB | Test #4 Enabled Profile Picture, S3 bucket | Test #5 Enabled Profile Picture, DB | Test #6 Enabled Profile Picture, S3 bucket |
TC: Search User | 500 | 44.5 | 35.87 | 33.4 | 40.51 | 43.94 | 55.71 | 49.61 |
TC: View User | 500 | 1138.1 | 677.6 | 619.49 | 609.09 | 573.09 | 586.37 | 575.99 |
TC: Edit User | 500 | 566.93 | 538.63 | 530.56 | 492.58 | 514.42 | 502.18 | |
TC: Save User | 500 | 27.39 | 26.06 | 26.59 | 20.24 | 21.22 | 22.57 | |
TC: View User After Save | 500 | 824.54 | 758.31 | 734.89 | 686.45 | 709.75 | 686.77 | |
TC: Total time in flow | 500 | 2132.32 | 1975.88 | 1941.63 | 1816.29 | 1887.47 | 1837.12 |
Service CPU Utilization
Tests #1, #2, #3
mod-users-b - 89%, mod-configuration-b - 38%
Test #4, #5, #6
During volume testing in tests #5 and #6 mod-users with S3 bucket utilized CPU 10% more than DB (S3 - 93%, DB - 83%).
Service Memory Consumption
mod-users - 68%, mod-inventory - 40%. No some weird behaviour from memory side
RDS CPU Utilization
CPU during volume tests grew from 17% to 30%. The results for RDS CPU utilization are not clear because of every 20 minutes spikes.
RDS Database Connections
Connections were close to 400 during all tests.
Appendix
Errors
- For all tests common errors (404/Not Found) were in GET /perms/users/{id} and GET /perms/users/{id}/permissions requests. These errors appear if [tenant]_mod_permissions.permissions_users table has no record with this user UUID in jsonb→>'userId'.
Methodology/Approach
- To get config Id and change storage source use API
- To upload picture to DB use API
- To get or to check uploaded profile picture use API where profileId the record in DB [tenant]_mod_users.profile_picture
- To connect AWS S3 bucket storage add to task definition of mod-users module and restart it with changes in revision
{ "name": "AWS_URL", "value": "https://s3.amazonaws.com" }
{ "name": "AWS_BUCKET", "value": "cluster-id-or-any-useful-naming-here" }
Infrastructure
Environment: PCP1
Release: Poppy (2023 R2)
- 9 m6i.2xlarge EC2 instances located in US East (N. Virginia)
- 2 instances of db.r6.xlarge database instances, one reader, and one writer
- MSK tenant
- 4 brokers
Apache Kafka version 2.8.0
EBS storage volume per broker 300 GiB
- auto.create.topics.enable=true
- og.retention.minutes=480
- default.replication.factor=3
Schemas and tables involved in testing:
- [tenant]_mod_users.users - 90068 records
- [tenant]_mod_users.profile_picture - 1800 records
- [tenant]_mod_permissions.permissions_users - 375 records
Modules