Stress testing Unity’s LLAPI, what are the limits?

Dec. 1, 2017
protect

(NetTest - a tool for stress testing the LLAPI, full Unity project download at the bottom!)

Seth, what the hell do you know about netcode, anyway?!

Woah, with the attitude already. Look, I'm all about multiplayer. Have been for a long time. I've gone from being excited to get two people walking on the same ANSI map in LORD2 in the early 90s to hitting the 70,000 concurrent user mark during busy times in Growtopia.

In addition to writing my own junk, I regularly play with Unity and Unreal and am constantly trying to see how they can fit my developing style - mostly I need them because it's becoming a losing battle to try to maintain your own 3D engine if you also want to actually design and release games too.

What's LLAPI, anyway?

LLAPI stands for Low Level Application Programming Interface. It's what Unity's HLAPI (High level) API is built on. I guess both of those can be called part of UNet. (Unity networking)

Why not just use the HLAPI like a normal person?

That might be ok for some projects, especially round-based networked games without too many players. When you are targeting MMO level network performance where a server may have to track stats of millions of players and simulate a world for weeks instead of minutes, the first rule is:

Stay as low level as you reasonably can.

I don't want someone else's net code to even think about touching my gameobjects, I just want it to deliver reliable/unreliable packets that I write/read straight bytes to. That's it. I want to handle things like prediction, dead reckoning, and variable serialization, myself!

What's the deal with UDP, TCP, and WebSockets?

Both UDP and TCP are internet protocols built on top of IP.

TCP is a bidirectional socket based connection that insures your data is correct and sent in the right order.

It's like calling Jeff, he picks up the phone and you can both talk until one of you puts the phone down. Oh, and after you say something, you make sure Jeff understood you correctly each time, so that eats up a bit of time.

UDP is is a stateless connection where single packets get sent. You write your message on a rock and throw it at Jeff's window. While it gets there fast, it's possible you'll miss and Jeff will never see it. If dozens of people are throwing rocks, he needs to examine each one carefully to figure out which pile to put it with so the text is attributed to the right thrower. He might read the second rock you threw before the first one.

WebSockets are basically TCP with a special handshake that's done over HTTP first. To continue this already questionable analogy, it's as if you had to call Jeff's mom for permission, and then she gave you his cell number to call.

In theory WebSocket performance could be similar to TCP but in practice they are much slower and unreliable, I don't really know why but hey, that's what we get. I suspect this will improve later.

For games, UDP is nice because you can send some of your packets fast with no verification that it was received, and others (more important packets, like dying) with verification which sort of makes those packets work like TCP.

That said, many most games probably would be ok with a straight TCP steam as well and having a connected state can make things easier, like easily applying SSL to everything and not worrying about unordered packets.

Why use WebSockets instead of UDP or TCP? Just use UDP or TCP for everything, moran

BECAUSE I CAN'T! Browsers won't allow the Unity plugin to run anymore, they just allow straight javascript/WebGL these days. It hurts. I mean, I wrote a cool multiplayer space taxi test for Unity using TCP sockets and now nobody can even play it.

What does LLAPI use?

It can read from both sockets (UDP) and WebSockets at the same time and route them so your game can let them play together. But how fast is it, and does it work? This brings us to the second rule of netcode:

Use stress tests without game code to notice glaring problems early and more clearly

Which finally brings us to the point of this post. NetTest is a little utility I wrote that can:

  • Run as a client, server, or both

  • If you connect as "Normal client" you can all chat with eachother

  • Run with a GUI or as headless (meaning no GUI, which is what you want for a server usually)

  • Can open "Stress clients" for testing, a single instance can open 100+ clients sockets

  • When stress mode is turned on, the stress clients will each send one random sentence per second. The server is set to re-broadcast it to ALL clients connected, so this generates a lot of traffic. (300 stress clients cause the server to generate 90K+ packets per second for example)

  • Server can give interesting stats about packets, payload vs Unity junk % in the packets, bandwidth and server speed statistics

  • Built in telnet server, any telnet client can log on and get statistics directly or issue commands

  • Tested on Windows, linux, WebGL

  • Supports serializing variables and creating custom packet types, although the stress test only uses strings

  • Everything is setup to push performance. Things that might mess with the readings like Unity's packet merging or modifying values based on dropped packets is disabled. All processing is done as fast as possible, no throttling or consideration to sleep cycles.

  • Keep in mind a real game server is going to also being doing tons of other things, this is doing almost nothing CPU wise except processing packets. Testing things separately like this make it easier to see issues and know what the baseline is.

ABOUT TEST RESULTS

These tests are presented 'as is', do your own tests using my Unity project if you really want exact info and to check the settings.

My windows machine is a i7-5960X, the remote linux box is similar and hosted on a different continent, I get a 200 ping to it.

All packets in NetTest are being sent over the 'reliable' channel. No tests involve p2p networking, only client<>server.

Settings:


config.AcksType = ConnectionAcksType.Acks32; //NOTE: Must match server or you'll get a CRC error on connection
config.PingTimeout = 4000; //NOTE: Must match server or you'll get a CRC error on connection
config.DisconnectTimeout = 20000;//NOTE: Must match server or you'll get a CRC error on connection
config.MaxSentMessageQueueSize = 30000; 
config.MaxCombinedReliableMessageCount = 1;
config.MaxCombinedReliableMessageSize = 100; //in bytes
config.MinUpdateTimeout = 1;
config.OverflowDropThreshold = 100;
config.NetworkDropThreshold = 100;
config.SendDelay = 0;

 

TEST 1: 300 CLIENT IDLE (LOCALHOST, WINDOWS BOX)

Ok, here I'm curious how many bytes LLAPI is going to use with clients doing nothing.

Server is set to localhost. I've got 4 NetTest's running - the one on the bottom right has had "Start local host" clicked, and the three others each have added 100 stress clients.

Results:

  • Around 30 bytes per stay alive packet per client. (23KB total over 7.74 seconds, sent 2.2 packets per client over 8 seconds, so roughly what I would expect for the 4000 ms ping timeout setting) Are stay alives sent over the reliable channel? Hmm.

  • Adding and removing test clients is a blocking operation and gets progressibly slower as more are added - why does it get slower and cause my whole system to act a bit weird?

  • While closing the instances looks normal, the instances are actually spending an additional 30 seconds or so to close sockets that were opened

JikGuard.com, a high-tech security service provider focusing on game protection and anti-cheat, is committed to helping game companies solve the problem of cheats and hacks, and providing deeply integrated encryption protection solutions for games.

Read More>>