- Time: 1:00pm Eastern Standard Time US (UTC-5)
- Dial-in Number: (712) 775-7035
- Review assessed relevance and reusability of prior work in Fedora testing
- F4 performance benchmarking (summary)
- Unimplemented "Technical Working Group" performance assessment plan
- Establish consensus on categories of next round of F4 performance benchmarking
- Define actions towards initial benchmarking
- Define actions towards collecting representative datasets and infrastructure
- Next meeting? Tues Dec 1st or Thurs Dec 3rd?
- Prior performance benchmarking and assessment work
- Three of the performance areas highlighted previously have not yet been sufficiently tested
- total data size
- ingest rate
- LDP/SPARQL Update performance (per Hydra practice)
- Clustering
- Primary use case seems to be high availability
- What increased scale clustering affords is unclear, partly because we haven't yet fully probed how far a single instance scales (as a baseline)
- Would be good to know how performance (response time) changes:
- as a file size increases
- as # of files increases
- as # of resources/containers increases
- We endeavor here to establish a process & baselines for the more isolated tests (1a in the agenda) so that we can make progress on "real-world"-type tests (1b in the agenda)
- How should we treat other axes?
- authorization
- transactions
- concurrency
- versioning
- Decision: Defer at first, then examine later once the process & baselines are clear.
- Decision: Process should include writing a number of objects/files into the repository (testing the speed of the writes)
- Every so often (# of writes), test a suite of operations (gets, deletes) to see how the speed of those change
- That way we test reading, writing, and a number of other operations as overall repository size increases.