|
To verify the result, I used the same JMeter checkin/out script but disabled all API calls in the workflow except the checkout-by-barcode one. The test was done on a standard perf env with the code from folio stable site on 2018-02-15. The test sends 60 requests in 60 seconds ramp-up window. Each request looks like checkout.txt and the barcode is selected from a pool and is different for each request. The JMeter log is in checkout_60_60.log and the result is in
In summary: checkout-bar-code has similar performance pattern to checkin-by-barcode, even though a single call on an idle system is not slow (under 2 seconds). When there are multiple concurrent checkout API calls (60 requests in 60s ramp-up window), each individual API call suffer some latency but better than checkin (average is 20 seconds, between min 3s to max 36s). Also the throughput is still good (49 requests per minute). Behind the scene, checkout-by-code API also makes multiple other API calls, see attached log files for mod-circulation.log , mod-circulation-storage.log , and mod-inventory-storage.log . Furthermore, I noticed that mod-circulation module will stop working if sending too many requests too fast. For example, initially I was using the same 100 requests in 60 seconds (as in checkin test case), mod-circulation stopped working and could not recover by itself after waiting long time. I had to restart it. It is possible that some resources (socket for example) were not released quickly/properly in in mod-circulation.
|
|
In my tests last night I saw the following error in 2/10 calls to circulation/loans. This may be related.
Failed to fetch loans from storage (500:ErrorMessage(fields=Map(Line -> 784, File -> postinit.c, SQLSTATE -> 53300, Routine -> InitPostgres, V -> FATAL, Message -> remaining connection slots are reserved for non-replication superuser connections, Severity -> FATAL)))
|
|
Update: above db error is not related. As discovered in
CIRC-225
Closed
, it is due to mod-circulation makes http connection to itself through Okapi, so the default http connection pool of 5 is exhausted. To make reproducing the problem easier, I also added a separate JMeter test for it.
|