...
In Review
Expand Jira server DuraSpace JIRA jqlQuery filter=13100 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets resolved this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Notes
- Announcements
- North American User Group
- Pilots / Testing
- Performance testing by Andrey, Peter and Jared
- Andrey and Jared were seeing fairly bad performance
- Andrey has performed the same tests on Fedora 4 and 5, and is seeing significantly worse performance on 6
- Will check to see what the specs of the machine running the tests were
- Peter and Danny have been unable to reproduce the poor performance
- Andrey and Jared were seeing fairly bad performance
- Including search index commits in same DB commit as the other db commits seems to maintain normal performance
- Search queries are fast except when getting back RDF types. Danny is working on resolving this in a separate PR.
- Comparing POSTs and PUTs - Jared reported that PUTs were a little bit slower
- Single object vs Multi-object transactions
- At the moment all transactions assume they are multi-object
- It may reduce the database latency significantly if single object transaction commits were implemented, but at the cost of considerable complexity
- what percentage of the latency is due to database? To determine how much of a concern this is.
- Calvin testing migration-util with larger heap, checksum turned off
- Initially faster, slowed back down to 25k per day after about 1.5 million objects
- Previous runs used about 30% memory, but not it is only using about 7%
- It seems to still be processing image files, which are not particularly large
- UVA originally ran their migration before alpha2, had significantly slower performance in their second migration after alpha2
- Ben C created a ticket to look into slow resumption of migration-util, which iterates back through all the Fedora 3 objects.
- Performance testing by Andrey, Peter and Jared
- Pre release short list of bug fixes and improvements
- Any new tickets/issues to be considered for the release
- Other topics
- fcrepo-java-client
- Need to follow through on java 11 update and update of integration tests.
- Thomas will take a look at the existing two tickets for updating it
- Modeshape
- Danny will look at the gh actions PR
- Will update Seth's PR to run gh actions to make sure tests pass
- We will review the unreleased updates to modeshape since the last release was cut, to determine if we want to sync up our fork
- ocfl-java database
- Peter will be checking on its usage of postgres for inventory caching and distributed object locking, as there are additional costs incurred by its use of separate processes per connection that he had not realized
- fcrepo-java-client
Actions
- Look through migration util commits since December to see if there are any potential causes of performance drop off.