| Table of Contents |
|---|
...
The purpose of these set of tests is to measure performance of Lotus release and to find possible issues, bottlenecks. PERF-231 , PERF-233 OAI-PMH Lotus release -performance testing IN PROGRESS
...
- Average response time per request with resumption token 0.852s ( compared to KIWI's 0.874s. (+36%)).
- No memory leaks or unexpected CPU spikes
- Issue with long response time due to absents of underlying records for instances that may lead to timeouts is still exists MODOAIPMH-390
- Incremental calls performed - 35,667 (PTF data set). Test failed due to timeout.
- Incremental calls performed - 99,477 (Bugfest data set 1 user and 20 DB connections)*.
- Incremental calls performed - 43,968 (Bugfest data set 1 user 35 DB connections)*
- Incremental calls performed - 68,350 (Bugfest data set 5 users and 20 DB connections)*
* Note: Bugfest dataset was used because it has more SRS records than PTF's dataset.
...
- Two identical tests may have different number of calls from edge-oai-pmh because mod-oai-pmh retrieves instances from the database in random order and in case if there are no underlying records for instances it will call DB one more time. While this process occurs in random order it may cause different number of calls to harvest same amount of data.
- A risk of client timeouts can occur if the dataset is missing a lot of underlying SRS records exists
- There is large number of timeouts while data transferring from inventory-storage to oai-pmh which can lead to data loss (and also may cause different number of requests from client side to complete a job).
- All tests ended as expected and without the errors on client side. And it looks like Lotus is more stable than Kiwi.
- Test with 35 DB_MAXPOOLSIZE is less stable due to more database timeouts occurring on mod-oai-pmh, as the result ±40% records was missed.
- For
we performed 5 concurrent harvests, which seemed to be working as expected (and each harvest worked on a separate process, having a different request_id). However due to the high load initially there were lots of DB connection timeouts on mod-oai-pmh, as a result the number of instances got transferred were less than expected. Below is an example of the numbers of instances that got transferred from mod-inventory-storage to oai-pmh database for each of the concurrent harvests (Number of instances expected in a transfer is 8158821(verified by one user)).Jira Legacy server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key PERF-233
...
Then finally container failed. We have heap dump created automatically and can share it additionaly
heap dump leak suspects:
