Overview 

The purpose of this test is to measure performance of Title Level Request workflow 

Environment

• mod-circulation:23.0.1
• mod-circulation-storage:14.0.0
• mod-inventory:18.1.4
• mod-inventory-storage:23.0.2
• okapi:4.13.0

Summary

Below you can find results of 4 subsequent tests on create Title Level Request. Few notable observations:

• ERROR rate is low 0,0007% of all requests
• High response time at the beginning of a test were made by caching process.
• "Failed to publish LOAN_DUE_DATE_CHANGED event: loan is null" Error, appears each time after making title level request  CIRC-1503
• Duplicate request is defined during creating of a test script (JIRA)
• No Memory leaks were defined
• CPU usage is intended, without sudden spikes and anomalies.
• Average response times for 5 users tests (for create TLR, lookup user, retrieve instance data transactions (including all related calls)):
  • While caching going
    • Get instance transaction 8.159
    • Create TLR.  1.054
    • Get users 0.212 
  • After caching is done:
    • Get Instance transaction 0.657
    • Create TLR. 0.820
    • Get users 0.160
• Average response times for 5 users tests (for create TLR, lookup user, retrieve instance data transactions (including all related calls)):
•  Caching is done:
  • Get instance transaction 0.657
  • Create TLR.  0.820
  • Get users 0.160

http://carrier-io.int.folio.ebsco.com/grafana/d/q69rYQlik/jmeter-performance?orgId=1&from=1650011350703&to=1650031630253&var-percentile=95&var-test_type=baseline&var-test=TLR&var-env=int&var-grouping=1s&var-low_limit=250&var-high_limit=700&var-db_name=jmeter&var-sampler_type=All

Test results

On screenshot above you can see differences  in response times with caching process and without it. (Spikes of response times).

 Buffer cache ratio chart

At the beginning of a test cache being involved into process. It's expanding high response times at the beginning of a test

Also DRS CPU utilisation is much higher when cache is involved.