Protocol for broadcasting to a lot of users quickly

Started by
12 comments, last by JohannesDeml 3 years, 6 months ago

Thanks a lot for your detailed reply, I'm always learning something new from your input!

Tackling the challenge of running the tests on two or more machines would for sure be interesting, but seems like a quite big task to solve on my own. Is there any library out there, that helps running programs and communicating between different machines (possibly even mobile devices)?

I implemented another Benchmark using .NETs EventPipeProfiler to collect information about garbage allocations (only in the managed code of course). The source data can be found in the 0.5.0 Release.

Results Version 0.5.0

None

Advertisement

Depends on what the tests are, I didn't try it with multiplayer games specifically myself, but for server side and library stuff, generally in order of simplest:

Unit tests using a mocked networking stack entirely, to make sure all the logic, packet handling etc is right.

Unit test like performance benchmarks. I found a lot of performance is down to general logic CPU/code. So can benchmark, profile and optimise a lot easily right there on a system without a remote.

But want some real world test data to be replaying ideally.

Run both client and server on the same system. This has some effects due to system resources allocation, but it gives me both things easily in one debugger session and one profiler view.

Run clients on multiple virtual machines (potentially on multiple hosts). This really gets into load testing, but more complex to set up and needs a lot of hardware resources which even at places i have worked is finite. Since it's not the main day to day testing spinning up a lot of nodes on say AWS can be fairly cheap once you script it all.

I tend to use SSH and file shares for this, both on Windows and Linux. File shares make copying builds, logs, etc. easy. Then SSH to run the client installer and then client program.

I use the VM environments APIs to manage all these nodes so that they stay in a completely clean state.

I might run whichever part of the system i am primarily working on locally for better debugger/profiler/etc experience.

There is remote debugging, I tend to avoid it unless I can't reproduce the issue on my local system (sometimes bugs are environment dependent).

Graphical interaction with the client programs is a pain, I try to avoid it. Make sure everything needed to connect to the server can be provided on the command line or config file, and consider having some useful outputs on STDOUT.

Mostly just having them connected is fairly useful, could maybe have them run an ai/bot, not seen it done.

In past for web stuff have used selenium and those scripts can be run over SSH. Or just recruited everyone in the office.

---

Mobile devices are more complex, for server testing I try to stick with a test client program that can run under normal Linux/Windows without a GUI maybe.

Or would have to decide if the Android emulators are good enough for you. Otherwise could use a lot of phones but sounds an expensive pain. There are APIs to install an apk and push config so again will immediately connect to your test server.

For main client testing and profiling again I just use a local device.

Hi @sync views,

thanks a lot for your input! That's good to hear. This is pretty much what I had in mind: Building the Server and client in one solution (with the client code and common code being in a separate repo as a submodule), so I can do unity tests very easy with headless clients. I plan to work on some very simple bots as well and will keep in mind to also include a --verbose setting in order to get nice output to understand what is going on. Recording games to replay them sounds also very interesting, I didn't think of that so far!

SyncViews said:
Run both client and server on the same system. This has some effects due to system resources allocation, but it gives me both things easily in one debugger session and one profiler view.

Yeah, totally, it really makes everything a lot easier. I think for my needs it should be enough to do most of the tests on the same machine and stress tests “manually”. AWS could be an interesting option as well, I'll keep that in mind if I need to do more load tests. Maybe I could also have bots started by the CI whenever there is a new version, Could be helpful for just having clients connected as you said.

None

This topic is closed to new replies.

Advertisement