| Table of Contents | ||
|---|---|---|
|
...
- 79 back-end modules deployed in 153 ECS tasks (changed. In Lotus, it was75 back-end modules deployed in 159 ECS tasks)
- 3 okapi ECS tasks
- 10 m6i.2xlarge EC2 instances (changed. In Lotus it was 9 m5.xlarge)
- 2 db.r6g.xlarge AWS RDS instance
- INFO logging level
- mod-inventory (running tasks -2)
- 1024 CPU units, 1684 MiB
- mod-inventory-storage (running tasks -2)
- 1024 CPU units, 1684MB mem
- mod-circulation (running tasks -2)
- 1024 CPU units, 896MB mem
- mod-circulation-storage (running tasks -2)
- 1024 CPU units, 1024MB mem
- mod-pubsub (running tasks -2)
- 1024 CPU units, 1296 MiB
- mod-patron-blocks (running tasks -2)
- 1024 CPU units, 896MB mem
- mod-feesfines (running tasks -2)
- 128CPU units, 896MB mem
- mod-authtoken (running tasks -2)
- 128 CPU units, 896MB mem
- okapi (running tasks -3)
- 1024 CPU units, 1360 MB mem
High Level Summary
- Morning Glory performs much better than Lotus response times for check-ins are mid 400ms, checkout 600ms - 800ms, with little variations between 1 and 50 users
- Worst-performing APIs are only POST /checkin-by-barcode and POST /checkout-by-barcode. They have improved since Lotus, now averaging in the mid 200ms even in the 50 users scenario.
- GET /circulation/loans takes 107ms in the 20 users and 50 users cases.
...
Test | Virtual Users | Duration | Load generator size (recommended) | Load generator Memory(GiB) (recommended) |
1. | 1 user | 30 mins | t3.medium | 3 |
2. | 5 users | 30 mins | t3.medium | 3 |
3. | 8 users | 30 mins | t3.medium | 3 |
4. | 20 users | 30 mins | t3.medium | 4 |
| 5. | 50 users | 30 mins | t3.large | 6 |
| 9. | 20 users longevity | 16 hours | t3.xlarge | 14 |
Results
Response Times (Average of all tests listed above, in seconds)
...
API | 1 user MG (75th %tile) | 1 user LT (75th %tile) | 5 users MG (75th %tile) | 5 users LT (75th %tile) | 8 users MG (75th %tile) | 8 users LT (75th %tile) | 20 users MG (75th %tile) | 20 users LT (75th %tile) | 50 users MG (75th %tile) | 50 users LT (75th %tile) |
|---|---|---|---|---|---|---|---|---|---|---|
| POST checkout-by-barcode | 296 | 435 | 217 | 330 | 211 | 349 | 204 | 384 | 205 | - |
| POST checkin-by-barcode | 275 | 386 | 199 | 298 | 199 | 315 | 189 | 348 | 186 | - |
| GET circulation/loans | 152 | 222 | 113 | 161 | 109 | 172 | 107 | 196 | 107 | - |
| GET inventory/items | 60 | 97 | 44 | 71 | 40 | 67 | 39 | 75 | 41 | - |
Longevity Test
Longevity test shows that Check Out response time increased as time went on, but not as aggressive as in Lotus.
| Check In | Check Out | |
|---|---|---|
| 1st Hour | 0.389s | 0.633s |
| 8th Hour | 0.348s | 0.666s |
| 15th Hour | 0.364s | 0.754s |
In the response time graph below the Checkout Controller time, which gathers all check-out API response times), increased over the 16-hours window, from just 0.633s to 0.754s.
...
The timeline highlighted below encompasses all 5 test runs (1, 5, 8, 20, and 50 users).
Modules CPUs and Memory Utilization
...