Overview  

JMeter script was used with the 40 requests per minute throughput limit that helped to obtain full harvesting successful results. The throughput limit usage, honestly, isn't a simulation of real user behaviour. The purpose of the current OAI-PMH tests is to measure the performance of the Orchid release by the EBSCO Harvester recommended tool and to find possible issues, and bottlenecks per PERF-510 - Getting issue details... STATUS

Summary

• Tests were executed by EBSCO Harvester in the AWS ptf-windows instance. There is no control of the 40 requests per minute throughput limit as it was done by the Jmeter script. That is why a successful harvesting operation by EBSCO Harvester took less time (~18 hours) than by JMeter script with a throughput limit (~25 hours). Moreover, EBSCO Harvester has a retry functionality that helps to keep on harvesting even after failed time-out requests.
• When the mod-oai-pmh.instance table gets accumulated with instance UUIDs from previous harvests, as was when the PTF env mod-oai-pmh.instance table reached 30M records, it took more time to insert new records into the table, therefore the overall duration of creating (downloading) new 'instanceUUIDs' records was increased as well.  (Not a critical issue).
• '(504) A gateway timeout' were caused by mod-oai-pmh 'java.lang.OutOfMemoryError: Java heap space'. On the other hand, the 'java.lang.OutOfMemoryError' exceptions appeared when not all 'instanceUUIDs ' records were created for the request. The reason why it happens should be investigated additionally.
• 'repository.fetchingChunkSize=8000' option increased the duration of the harvesting request. The default value (5000) shows optimal results.
• All test executions show similar Service Memory behaviour.  Only after restarting the service, the service memory usage is in an optimal level. After the harvesting operation starts, Service memory usage is grown up to 99%, stabilized on this level, and doesn't change reached value (even for future harvesting processes).   
  On the one hand, investigating how much memory is used per harvesting is unavailable. On the other hand, the reason why Service memory usage is not decreased if there are no activities should be investigated additionally as it could be a functionality of AWS displaying aggregated memory of the containers or could be a FOLIO issue.
• In case all 'instanceUUIDs ' records have been created for the request as expected (ocp2 - 10'023'100 'instance' records) with different 'repository.fetchingChunkSize' (5000, 8000), the harvesting operation was less than 24 hours and was completed successfully. But the instability of the harvesting operation for Orchid release due to not all 'instance' records being created for the request should be investigated and fixed by MODOAIPMH-509 - Getting issue details... STATUS

Recommendations & Jiras

MODOAIPMH-509 - Getting issue details... STATUS

Test Runs & Results

The table contains information about test executions, their results, 'mod-oai-pmh' service configuration:

Comparisons

Comparison with full harvesting testing by JMeter script OAI-PMH data harvesting (Orchid)

The integrity of the harvesting was not checked

Memory Utilization

Successful test (#13)

'mod-oai-pmh' uses ~100-102% of Memory during harvesting (assumption: Memory was reserved by previous test up to 99%)

Failed test (#11)

'mod-oai-pmh' uses ~99% of Memory during harvesting (assumption: Memory was reserved by previous test up to 99%)

CPU Utilization 

Successful test (#13)

'mod-graphql' had a quite big CPU usage spike up to 1653 units during harvesting (one-time incident).

Failed test (#11)

'mod-oai-pmh' uses up to ~97% of CPU during harvesting.

The spike in CPU utilization is probably due to the activity toward the end of the test when it was running out of memory and the Operating System was trying to clear whatever memory it could and/or swapping out blocks of memory to keep the process alive - until it cannot do it anymore and everything toppled

RDS CPU Utilization 

Successful test (#13)

The highest spike was up to 76% of RDS CPU usage for ocp2-db-01

Failed test (#11)

Additional information from module and database logs 

2023-04-12T13:41:07.262+02:00 % Total % Received % Xferd Average Speed Time Time Time Current

2023-04-12T13:41:07.262+02:00 Dload Upload Total Spent Left Speed

2023-04-12T13:41:11.118+02:00 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 1 544M 0 0 1 9024k 0 77.9M 0:00:06 --:--:-- 0:00:06 77.3M 37 544M 0 0 37 203M 0 183M 0:00:02 0:00:01 0:00:01 183M 61 544M 0 0 61 336M 0 159M 0:00:03 0:00:02 0:00:01 159M 84 544M 0 0 84 461M 0 148M 0:00:03 0:00:03 --:--:-- 148M 100 544M 0 0 100 544M 0 141M 0:00:03 0:00:03 --:--:-- 141M

2023-04-12T13:41:14.898+02:00 11:41:14 [] [] [] [mod_oai_pmh] INFO RestRouting invoking getAdminHealth

2023-04-12T13:41:14.898+02:00 11:41:14 [] [] [] [mod_oai_pmh] INFO LogUtil 127.0.0.1:50906 GET /admin/health null HTTP_1_1 200 4 0 tid=null OK

2023-04-12T13:41:14.898+02:00 11:41:14 [] [] [] [mod_oai_pmh] INFO RestRouting invoking getAdminHealth

2023-04-12T13:41:14.898+02:00 11:41:14 [] [] [] [mod_oai_pmh] INFO LogUtil 127.0.0.1:47758 GET /admin/health null HTTP_1_1 200 4 0 tid=null OK

2023-04-12T13:41:16.937+02:00 11:41:14 [] [] [] [] ERROR ? Unhandled exception

2023-04-12T13:41:16.937+02:00 java.lang.OutOfMemoryError: Java heap space

2023-04-12T13:41:16.937+02:00 at java.util.Arrays.copyOf(Arrays.java:3745) ~[?:?]

2023-04-12T13:41:16.937+02:00 at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172) ~[?:?]

2023-04-12T13:41:16.937+02:00 at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:686) ~[?:?]

2023-04-12T13:41:16.937+02:00 at java.lang.StringBuffer.append(StringBuffer.java:414) ~[?:?]

2023-04-12T13:41:16.937+02:00 at java.io.StringWriter.write(StringWriter.java:99) ~[?:?]

2023-04-12T13:41:16.937+02:00 at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120) ~[?:?]

2023-04-12T13:41:16.937+02:00 at java.io.BufferedWriter.flush(BufferedWriter.java:256) ~[?:?]

The following screenshot is an example of the memory profiling results:

Appendix

Methodology/Approach

Before running OAI-PMH for the first time, please run the following database commands to optimize the tables (from https://folio-org.atlassian.net/wiki/display/FOLIOtips/OAI-PMH+Best+Practices#OAIPMHBestPractices-SlowPerformance):

REINDEX index <tenant>_mod_inventory_storage.audit_item_pmh_createddate_idx ;
REINDEX index <tenant>_mod_inventory_storage.audit_holdings_record_pmh_createddate_idx;
REINDEX index <tenant>_mod_inventory_storage.holdings_record_pmh_metadata_updateddate_idx;
REINDEX index <tenant>_mod_inventory_storage.item_pmh_metadata_updateddate_idx;
REINDEX index <tenant>_mod_inventory_storage.instance_pmh_metadata_updateddate_idx;
analyze verbose <tenant>_mod_inventory_storage.instance;
analyze verbose <tenant>_mod_inventory_storage.item;
analyze verbose <tenant>_mod_inventory_storage.holdings_record;

1. Execute the following query in a related database for removing existed 'instances' created by previous harvesting request and a request itself:

TRUNCATE TABLE fs09000000_mod_oai_pmh.request_metadata_lb cascade

2. Get access to the ptf-windows machine for running EBSCO Harvesting (contact person Artem Vronik ). The following cmd command (cmd should be run in the same directory as EBSCO Harvester) start EBSCO Harvester:

OAIPMHHarvester.exe -HarvestMode=full -DefinitionId=Orchid -HarvesterWebClientTimeout_Seconds=0s=0

3. Monitor service hardware metrics (suggest using MAX aggregation for Service CPU and Memory usage) and logs during a test execution