Get Circulation/loans queries


IN PROGRESS 

Overview:

  1. PERF-83 - Getting issue details... STATUS

Using the Carrier-io framework and CloudWach for capturing and analyzing performance test results we've done few tests (1,5,8 users) to understand how various layers contribute to the final response time moreover,compare and find differences between two queries on the same API call

API call to test: 

GET /circulation/loans
Queries to test::

  • ?limit=2147483647&query=(itemId==${current_item} and status.name==Open);

  • ?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*").

Tests are done with 1, 5, 8 users. 

Test data used : ItemID.csv

Version:

Okapi

  • Version 3.1.2
  • circulation 19.0.9

High Level Summary

There are 2 test set with the three tests each. 1,5,8 users for GET /circulation/loans?limit=2147483647&query=(itemId==${current_item} and status.name==Open) and 1,5,8 users for GET /circulation/loans?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*").  

Second one is much faster than the first one.


Test Runs:

TestVirtual usersQueryProfiledDuration in secondsRamp Up in seconds
11?limit=2147483647&query=(itemId==${current_item} and status.name==Open)

no

1800

0

25?limit=2147483647&query=(itemId==${current_item} and status.name==Open)no180050
38?limit=2147483647&query=(itemId==${current_item} and status.name==Open)no180080
41?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*")no18000
55?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*")no180050
68?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*")no180080


Results:

As you can see from table below- there a big difference between 75 percentiles for ?limit=2147483647&query=(itemId==${current_item} and status.name==Open) (1 user- 289 ms, 5 users-357 ms, 8 users - 414 ms) 

and for ?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*") (1 user- 41 ms, 5 users-51 ms, 8 users - 58 ms). Which means that second query are much faster that the first one, that's why I would recommend to use second one ?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*").

Comparison of test runs below:

TestVirtual UsersRequestsTotalOK75th pct95th pct99th pctMax
Test 11GET_circulation/loans?limit=2147483647&query=(itemId==${current_item} and status.name==Open)638963890.2890.3310.3791.454
Test 2526097260970.3570.4220.511.399
Test 3849808322210.4140.5020.64917.104
Test 41GET_circulation/loans?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*")40467404670.0410.0560.1181.281
Test 551702351702350.0510.0740.244.08
Test 6 82474712474710.0580.0870.1567.27


Comparison chart:


As you may see new query (lines at the right end) working way much faster

8 Users tests backend comparison:

Old query: (?limit=2147483647&query=(itemId==${current_item} and status.name==Open)) 8 User test

Instance CPU utilization:


Service CPU utilization

DB CPU utilization:

DB queries:

Note: one duplicate index found, but it appears often on other tests. No slow queries found.


Giraffe Chart




New query: (?limit=2147483647&query=(itemId==${current_item} and status.name=="Open*")) 8 User test

Instance CPU utilization

Service CPU utilization

DB CPU utilization

DB queries (one slow query found) :


Note that using new query we'll have less instance and service level CPU utilization however it produces higher DB CPU usage.


Giraffe Chart

Note: As you can see, the the giraffe chart contains less inside calls that the previous one. That may explain slowness of old query .