Use cases for Testground

I recently noticed the announcement of the Testground project here And I was wondering what the different use cases are. For example can Testground help me benchmark a move from a server-client architecture to a peer to peer one?

For example, let say I have a file sharing setup, where a cluster of servers (lets say 3 servers) makes files available for clients to download.

Let say I then convert this server-client to use IPFS, where files are shared in a P2P version…

Can I:

use testground to benchmark the client-server setup and also
use tesground to benchmark the p2p setup
and then compare the performances of the two?

Hey @finlaybweber!

Thanks for posting your question. I’m glad you’re considering taking Testground out for a spin to compare how a change in architecture would impact your use case.

I would create 1 test plan with 2 test cases. Provided that your app is written in Go, you can use testground/sdk-go. Take a look at the example plans to get started.

Test case A: client/server model:

  • Two groups (you can create as many instances as you want of each): servers, clients.
  • Servers would start the server process that serves content, and would publish their endpoint addresses on a topic via the sync service.
  • Clients would receive those addresses and request content from them, maybe using a random distribution of requests, or round-robin, etc. You choose.
  • You can record results via runenv.R().RecordPoint() or other methods.

Test case B: p2p model:

  • Two groups: seeds, leeches.
  • Seeds would create random files via runenv.CreateRandomFile() and would add them to the IPFS repo. @hector –– can you advise how to programmatically create an IPFS node (i.e. using ipfs as a library)? Here’s an example from that instantiates Bitswap, but we likely want a full node here.
  • You would publish the CIDs into a topic, as well as the endpoint addresses.
  • Seeds connect to one another in specific ways to pre-fetch some of these files, so then you’ll be able to witness the effect of parallelisation from the clients.
  • Leeches subscribe to CID and to endpoint addresses.
  • They connect to specific seeds and request CIDs.

Hope those notes help,

This is the canonical example:

unfortunately not. Java and Rust. Would this be an hindrance?

Translating the SDK to Java and Rust would be super simple. That would allow you to run test plans written in those languages. Would you like to take this on?