POST /inventory-hierarchy/items-and-holdings report


In Progress

In Progress

In Progress

In Progress

In Progress

In Progress

PERF-120 - Getting issue details... STATUS

Goals:

  • Define overall performance of POST /inventory-hierarchy/items-and-holdings;
  • Find bottlenecks if possible;
  • Measure KPI's for different number of instances included in request;
  • Measure KPI's for different number of holdings attached per instance ID;


Overview

Mod-inventory-storage has a new API to gather all related instances' data, i.e., items and holdings, in one call in order to eliminate making 3 separate calls to get the data. The API also allows passing in x number of instance IDs to lookup. Since teams are now starting to use this API, it's important to understand the stability of the API with respect to the module's CPU and memory usage, and also the database usage.

Summary

  1. System shows stable work and quick responses in all test
  2. No memory leaks found
  3. There is a link between most used modules (see CPU) and test type. In case if it's extremely fast responses (for example for 5 holdings per instance and one user) - most used module will be mod-authtoken, otherwise (see test 4) that will be mod-inventory-storage. Same for increasing number of instances per request.
  4. DB CPU usage reaches maximum in 8-users test
  5. Fast response for most high load test (test 4). To extract an instance having 300+ holdings it takes 373 ms for 75th percentile. Therefore getting one holding with this endpoint takes 1.2 ms.
  6. No bottlenecks found. 


Version:

"okapi-3.1.2";
"mod-inventory-storage-19.4.0-SNAPSHOT.448";

"mod-authtoken-2.5.1".


RDS Data amount:

Precondition, if database free memory is less than 2000 MB, DB instance should be restarted. 

Holdings per instanceNumber of instances
>07183552
>1

407467

>269890
>322241
>410201
>55635

>10

1060
>15516
>20331
>25240
>40

115

>100

23

>3007

Test Runs:

TestVirtual UsersDuration (min)Instance per requestHoldings per instance
1

1

3015
2

2

3015
31301 (adding instance to request each loop) max - 9645
41301300
513050>1
683050>1
7190(adding 5 instance to request each loop) max - 5325 >1


Results

Summary:

During test set we've measured  general performance of new endpoint.


Test 1: 1 user, 1 instance


RequestsTotalOKReq/sMin50th pct75th pct95th pct99th pct
[POST] /inventory-hierarchy/items-and-holdings365303653020.2940.0330.0400.0430.0570.101


Resource usage



Most used modules

  • Mod Authtoken
  • Okapi
  • Mod-Inventory Storage.


RDS resource usage

RDS memory usage


As you can see, all resources shows stable behavior. During whole test Memory and CPU usage hasn't spikes or anomalies. No slow queries was found.


Test 2: 2 users, 1 instance


RequestsTotalOKReq/sMin50th pct75th pct95th pct99th pct
[POST] /inventory-hierarchy/items-and-holdings623386233834.6310.0320.0420.0470.0650.115


Resources


Most used modules:

  • mod autotoken
  • okapi 
  • mod inventory storage




RDS memory usage

Comment: As you can see, 75 percentile response time for first and second test are almost the same (43ms VS 47ms) while request total number almost twice higher. That cases almost twice higher CPU usage on mod-autotoken.

Test 3: 1 user with incremental instances per iteration


RequestsTotalOKReq/sMin50th pct75th pct95th pct99th pct
[POST] /inventory-hierarchy/items-and-holdings263626361.4640.0440.6650.9841.2311.367


Resources


Most used module

  • mod-inventory storage


RDS memory usage

Test 4: 1 user, 1 instance with 300 holdings