Page Comparison

...

This is a report for a series of Check-in-check-out test runs against the Iris Juniper release. 

Backend:

• mod-circulation-22.0.0
• mod-circulation-storage-13.0.0
• mod-inventory-17.0.1
• mod-inventory-storage-21.0.0
• mod-authtoken-2.8.0
• mod-pubsub-2.3.1
• mod-patron-blocks-1.3.0
• mod-feesfines-16.1.0
• okapi-4.8.2

...

• GET automated-patron-blocks response time gets worse even with 1 user (46%) and exponentially worse with 5 users (53%), 8 users (78%), 20 users (259%)

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODPATBLK-94

• Database quickly runs out of memory, 2GB per 2 hours in a 8 users test, could be due to mod-patron-block queries. 

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key RMB-863

• Check-in time improved compared to Iris.
• See below for API calls consuming high CPU utilization percentage.
• mod-inventory-storage appears to have a slow gradual memory leak

  Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINVSTOR-751

...

Perhaps mod-inventory-storage's increase CPU is also due to an increase in memory usage. This indicates a memory leaks. Heap dump shows a leak of io.vertx.core.impl.DuplicatedContext. See

...

item_checked_out_event userId=="1d4adbf2-4a0c-4777-b495-f29d45bd1711" LIMIT 10000 already has a correct b-tree index (schema) since September 2020 (MODPATBLK-48 = PR 37). The long execution time of 2154 ms is caused by the high limit of 10000 records to fetch.

...

Searching item for barcode=="13137881" already has a correct b-tree index (schema.json) since March 2019 (MODINVSTOR-269). If it takes 606 ms this is probably caused by database server overload. We may get a slight speedup by changing the b-tree index into a unique b-tree index (MODINVSTOR-523).

Miscellaneous

• Raw test data: 

  View file
  name CICO-Juniper.xlsx height 250

...