How to test a distributed P2P game if it can handle 100 connections?

Question

For a big project at school we have made a P2P variant of the famous beergame. The GUI is built in JavaFX.

I have to do research on how to test a quality attribute scenario, which is the following:

100 players can connect to the game and play it.

Connecting to a game goes via an input in the GUI where the player needs to put the IP address (with port if its over WAN) of the host (gameleader). We are implementing RAFT as the state consensus algorithm.

The first step I did was researching the best possible way to create 100 clients/computers however you want to call it. I quickly came to the conclusion that Docker was about the only piece of software that could have 100 containers running simultaneously. My real problem now is how to test the application in a containerized environment.

I thought about it and the only real way to test the flow to play a game on each container was to walk through the UI elements with for each client other settings (every client needs to join the game with different usernames) with some kind of UI testing framework like TestFX.

I have found a framework that lets you test the UI, but it needs an host OS with a graphical interface to function (or at least, that's the assumption I have based on a short search on the internet).

Is there maybe a way to do this in IntellJ itself. Creating 100 containers of with the game with each an unique IP-address so that they can connect to the game host.

Edit for @Karol Dowbecki

The way we are communicating is sending serialized AppendEntries(heartbeats) every 100ms over TCP/IP with UPnP which contain changes that have to be committed (if nothing happened, then the appendentry has no logentries). So if a player does an action, it sents an AppendEntry to the leader of at that moment(gameleader/host) which then relays it back to all the other nodes and waits for the majority of the nodes to send it back (two-phase commit) after which it is added to the list of logentries of each player (all data of the game). If a new player joins the game, that player receives all of the logEntries that exist for that game in just 1 heartbeat, which is a gigantic serialized json object, after which it recalculates the steps (logEntries) from the bottom up until the last one, which is the player joined the game.

So what you are suggesting is capturing these serialized appendEntries that go over the network, deserialize them and compare it to the expected result? It will be very hard if I had to scan every AppendEntry, as each client sends 10 of them per second to the leader (if the client is a player) and 10 to all of the nodes (if the client is the leader/host).

Also the AppendEntries go back and forth. Everytime a player joins the LogIndex(the index of the LogEntries, basically the index of how many gamestate changes have occured) goes up by 1, which ultimately defines how many changes have occured in the gamestate. So its not that I am sending static information back and forth. Its changing with every joining player. Also when a player "disconnects" this affects the LogIndex again. I have to be able to keep track of the fact that 100 people joined the game and are still there.

Answer 1

You don't necessary have to create 100 instances of the game. Doing this will have one considerable downside, by scripting the client UI it's hard to tell if the bottleneck will be in the client or in the server (the Coordinated Omission problem).

If you understand what is the wire protocol used and what are the expected player behaviors you can create a test plan using Apache JMeter or Gatling. You can use Wireshark to inspect and record the wire protocol used by the client.

This won't create a true player experience but as long as you will recreate the most popular player's actions it will be good enough to stress test the server. Mentioned frameworks will also have a number of features that will help you spot the problem e.g. ramping up and down connections over a period of time, plotting the results, etc.