| Table of Contents |
|---|
...
Ticket: Jira Legacy server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key PERF-627
...
- Load tests showed that there is no significant influence of check-out lock on performance of the application.
- Average response time of check-out request is about 0.5s (level of load - 6.6 requests/minute).
Recomendations and Jiras
It would be usefull to implement some additional monitoring for the check-out lock feature. It can include such metrics as number of locks accross the users, locking history and rate of locking to closely monitor it for performance implications.
Test runs
| Scenario | Level of load | Configuration | Response time average | Response time 95perc |
|---|---|---|---|---|
| Check-out API | 10 virtual users, 20 requests each (during 30 minutes). Overal load - 6.6 requests/minute | Check-out lock enabled* | 0.558 | 2.152 |
| Check-out lock disabled | 0.513 | 0.556 | ||
100 virtual** users, 20 requests each (during 30 minutes). Overal load - 66 requests/minute | Check-out lock enabled* | 0.379 | 0.476 | |
| Check-out lock disabled | 0.336 | 0.391 |
...
At the screenshot we can see that lock is being created in check-out-lock-storage and then deleted almost at the same moment. Deletion of lock happens when check-out for item is done.
Appendix
Infrastructure
PTF -environment pcp1
- 10 m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1
1 database instances, writer
Name API Name Memory GIB vCPUs max_connections R6G Extra Large db.r6g.xlarge 32 GiB 4 vCPUs 2731 - MSK ptf-kakfa-3
- 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
...