Skip to end of banner
Go to start of banner

PTF - DI testing for Cornell (mod-srs, mod-srm connections)

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »










































Overview

  1. In this workflow, we are checking the performance of Data Import for Cornell. This testing is done to mimic Cornell load with increased DB connections in mod-srs and mod-srm.  PERF-555 - Getting issue details... STATUS


These tests were run in PTF env in cptf2 cluster

Following changes were made to env based on Cornell's load requirement:

1. Give up to 500 connections to mod-srm, mod-srs.

2. Make DB r6g.xlarge, 2xlarge, 4xlarge, 8xlarge Serverless v2 (0.5 - 128 ACUs), Serverless v2 (32 - 128 ACUs), Serverless v2 (16 - 96 ACUs), Serverless v2 (8 - 96 ACUs).

Summary


Data Import with the profile "EBSCO ebooks new and updated" causes a very high load on the database.

Increasing the number of connections for mod-srs & mod-srm to 500 (even to 100) severely increases database load and resource utilization.

One of the reasons is the huge volume of the database: for example, table mod_source_record_storage.marc_indexers has 1028022472 records in the database.

Data import with the profile "EBSCO ebooks new and updated" could run successfully with database sizes: db.r6g.2xlarge, db.r6g.4xlarge, db.r6g.8xlarge. With increasing database size we can observe decreasing data import job duration.

Increasing the number of connections for mod-srs & mod-srm to 500 (even to 100) causes database memory usage errors.

Test Runs

Aurora PostgreSQL ChangesDI duration with 30 mod-srs & mod-srm connectionsStatusDI duration with 500 mod-srs & mod-srm connectionsACUAverage ACUs per testMem (GiB)Price per hour $Baseline
price per month $
Additional expenses
Serverless v2 (0.5 - 128 ACUs)1 hour 3 minCompleted with errorsstopped due to DB error0.58410.09(per 0.5 ACU)64.80+Price per additionally used ACUs
Serverless v2 (32 - 128 ACUs)34 minCompleted20 min hanging 0% completed DB error3299640.18(per 1 ACU)4,147.20+Price per additionally used ACUs
db.r6g.8xlarge18 minCompletedstopped due to DB error--2563.5972,589.84No additional expenses
db.r6g.4xlarge29 minCompletedstopped due to DB error--1281.7981,294.56No additional expenses
db.r6g.2xlarge50 minCompletedstopped due to DB error--640.889640.00No additional expenses
db.r6g.xlarge2 hours -20% done.Could be completed with errors due to DB errorstopped due to DB error--320.45324.00No additional expenses
Serverless v2 (16 - 96 ACUs)45 minCompleted-1663320.18(per 1 ACU)2,073.60+Price per additionally used ACUs
Serverless v2 (8 - 96 ACUs)36 min (25 min when started right after the first one)Completed-883160.18(per 1 ACU)1,036.80+Price per additionally used ACUs

Note that the average ACU utilization for the database is approximately 4 ACUs without any activities in the environment. And each job, test, or any activity will cause additional ACUs utilization.

Explanation of the table above:

$0.18 per ACU Hour is the approximate average price for Serverless V2.

The price depends on the AWS region: for us-east N.Virginia - $0.12, for South America (Sao Paulo) - $0.25

When DB is already scaled up DI duration decreases( for example from 36 to 25 min when started right after the first one for Serverless v2 (8 - 96 ACUs)

For easier calculation of database price use https://calculator.aws/#/addService/AuroraPostgreSQL. Need to place average ACU utilization per month to get more accurate results.

Observations

To run parallel import jobs is impossible. All jobs will be run one by one.

 RDS Resource utilization

Serverless v2 (8,16 - 96 ACUs)


On these graphs, we can observe gaps that correspond to DB issues with increased connections for mod-srs and mod-srm to 500.


Appendix




  • No labels