Page Comparison

...

A 24-hour longevity test was performed (with Okapi 4.2.2). Key observations:

Image RemovedImage Added

• Performance degraded after 2 hours.
  • Average response time in the first two hours: 
    • Check-in:  2.28 sec
    • Check-out: 4.76 sec
  • Average response time in the first 12 hours:
    • Check-in: 2.709 sec
    • Check-out: 7.898 sec
  • Average response time in the last 12 hours:
    • Check-in:  4.605 sec
    • Check-out: 17.297 sec
  • Together the average response time for the entire test run:
    • Check-in: 3.414 sec
    • Check-out: 11.419 sec
• Throughput degrades over time, unsurprisingly
  • Image RemovedImage Added

• Modules Services CPU utilizations (The black lines indicate the start and finish time of the test run)
• Image RemovedImage Added
  • With the load of 20 users, Okapi started out working hardest, but its CPU utilization drops down over time. This is because mod-pubsub's is leaking HTTP Client and taking up more resources therefore slowing down, causing Okapi to not need to route messages as much. Clearly mod-pubsub's CPU utilization went up. The other modules follow Okapi's pattern.

• Services Modules Memory utilizations 
• Image RemovedImage Added
  • No modules exhibited memory leaks except for mod-pubsub
• Although there were two instances of mod-pubsub running on two different ec2 instances, mod-pubsub's traffic seemed to have been stickied to one instance. Here are graphs showing mod-pubsub's on one instance using up memory and CPU resources, and on another instance not showing much activities:
  • Image RemovedImage Added
  • mod-pubsub and Okapi on another node - Okapi's CPU utilization dwindles while mod-pubsub does not seem to be busy at all
  • Image RemovedImage Added

JVM Profiling

Database

...

https://issues.folio.org/browse/MODPATBLK-70

https://issues.folio.org/browse/OKAPI-964

https://issues.folio.org/browse/OKAPI-965