IN-PROGRESS
| Table of Contents | ||
|---|---|---|
|
...
- Kiwi performs much better than Juniper GA, response times for check-ins are <900ms, checkout <1500ms, with not much variation between 1 and 20 users
- Database performance is better and uses much less CPU compared to Juniper GA
- Worst-performing APIs are still POST /checkin-by-barcode and POST /checkout-by-barcode. The response time are still about 500ms. GET /circulation/loans also takes more than 200ms. GET /inventory/item (by barcode) takes less than 100ms now.
- Longevity test shows response times worsen over time, probably due to the growing DB CPU utilization.
Potentially could address this situationJira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key CIRCSTORE-304
Test Runs
Test | Virtual Users | Duration |
1. | 1 | 30 mins |
2. | 5 | 30 mins |
3. | 8 | 30 mins |
4. | 20 | 30 mins |
| 5. | 1 (repeat) | 30 mins |
...
API | 1 user JP (75th %tile) | 1 user KW (75th %tile) | 5 users JP (75th %tile) | 5 users KW (75th %tile) | 8 users JP (75th %tile) | 8 users KW (75th %tile) | 20 users JP (75th %tile) | 20 users KW (75th %tile) |
|---|---|---|---|---|---|---|---|---|
| POST checkout-by-barcode | 526 | 550 | 476 | 436 | 479 | 428 | 861 | 461 |
| POST checkin-by-barcode | 457 | 444 | 402 | 368 | 489 | 438 | 852 | 504 |
| GET circulation/loans | 246 | 305 | 245 | 262 | 272 | 267 | 516 | 303 |
| GET inventory/items | 171 | 124 | 166 | 96 | 170 | 92 | 250 | 99 |
Longevity
...
Test
Longevity test shows that the response time increased as time went on.
| Check In | Check Out | |
|---|---|---|
| 1st Hour | 0.821s | 1.476s |
| 16th Hour | 1.129s | 3.343s |
| 25th Hour | 0.999s | 3.758s |
In the response time graph below the Checkout Controller time, which gathers all chekc-out API response times), increased over a 16-hours window, from <2s to over 5s.
The DB CPU utilization percentage also increased over time
...
| Code Block |
|---|
Gather (cost=1000.00..60093.80 rows=780 width=966) (actual time=192.948..200.814 rows=1 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on loan (cost=0.00..59015.80 rows=325 width=966) (actual time=145.247..191.854 rows=0 loops=3) Filter: ((lower(fs09000000_mod_circulation_storage.f_unaccent((jsonb ->> 'userId'::text))) ~~ '664e4002-9eb2-4c9e-addd-04f308a8062c'::text) AND (lower(fs09000000_mod_circulation_storage.f_unaccent(((jsonb -> 'status'::text) ->> 'name'::text))) !~~ 'closed'::text)) Rows Removed by Filter: 53759 Planning Time: 0.212 ms Execution Time: 200.834 ms |
Due to the left() function (more details in
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Before and after fixing the left() function, there were spikes at half an hour interval, but these were due to background jobs processing the loans (age-to-lost, patron notices, etc..). As more loans got created during the test, the spikes got higher.
Here is a view of the CPU utilization. A couple of observations:
...
Here is the Service CPU Utilization graph without Okapi for better clarity of other modules' behaviors.
(Note that at around 8:00 (on the graph) there are extended spikes for all the modules, Okapi, and the DB. This is due to tooling. The tool for some reasons added another 20 concurrent users to the test. The results for this period had been discarded.)
There does not appear to be any memory leaks issues in Kiwi
Only mod---
A closer look at the CPU graphs without Okapi.
inventory-storage seems to have the spikes but but they were not prolonged and the processes did not crash.
Modules CPUs and Memory Utilization
...