3-dimensional memory/throughput benchmarks of go-graphsync

[raulk]

Goal: characterise memory load and throughput of graphsync+stores in isolation with everything else.

Assuming a perfect network, benchmark three dimensions:

Store dimension:

• badger2
• memory (control)
• filesystem (low prio)
• badger (low prio)

Payload size dimension:

• 1MiB
• 10MiB
• 100MiB
• 1GiB (⬇️ activated with a flag)
• 32GiB
• 64GiB

Concurrency dimension:

• 2^(0-8)

---

Use the custom metrics go benchmark API to record useful metrics.

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[raulk]

@dirkmc @nonsense @hannahhoward tagging you for input. There are some benchmarks we can work off in https://github.com/ipfs/go-graphsync/tree/master/benchmarks.

[raulk]

After the latest changes, the testground test plan already gives us the coverage we need. So writing the integration tests proposed here seems irrelevant.