How to optimize a server build ?

Hello,

We are working on an online multiplayer game in VR. We are using Playfab as gameservers and Mirror v30 for the Networking. It's a 1v1 competitive game, we already had optimize the network overload and we have a stable latency, so the problem is not about the network itself but about the memory usage of the build.

For now, the server build consumes 260mb of memory (with the batchmode and nographics options). We are investigating about this high usage and we see that ShaderLab is taking ~10mb, and our DLLs ~210mb.

The problem about ShaderLab exists in another thread but there is no other answer than "report an issue" : https://forum.unity.com/threads/headless-server.777614/

We must reduce the memory usage of the server build. It's impossible to allocate 400mb for two players. Can anyone has tips, ideas or everything that would help us ?

Spoiler: Configuration

The project is setup for IL2CPP, with .NET 4.x and C++ compiler in Debug.
We are using Unity 2019.3.15f1 with thoses plugins and libraries :

• Sirenix OdinInspector :
• Demigiant DOTween
• Mirror
• PlayFabSDK
• Steamwork.NET & steam_api

This is our manifest.json :

Code (JavaScript):

1. {
2.   "dependencies": {
3.     "com.unity.2d.sprite": "1.0.0",
4.     "com.unity.analytics": "3.3.5",
5.     "com.unity.ide.vscode": "1.2.2",
6.     "com.unity.inputsystem": "1.0.0",
7.     "com.unity.mobile.android-logcat": "1.1.1",
8.     "com.unity.nuget.newtonsoft-json": "2.0.0",
9.     "com.unity.probuilder": "4.2.3",
10.     "com.unity.progrids": "3.0.3-preview.6",
11.     "com.unity.settings-manager": "1.0.2",
12.     "com.unity.terrain-tools": "3.0.1-preview",
13.     "com.unity.textmeshpro": "2.0.1",
14.     "com.unity.timeline": "1.2.17",
15.     "com.unity.ugui": "1.0.0",
16.     "com.unity.xr.interaction.toolkit": "0.10.0-preview.7",
17.     "com.unity.xr.legacyinputhelpers": "2.1.4",
18.     "com.unity.xr.management": "3.2.15",
19.     "com.unity.xr.oculus": "1.3.4",
20.     "com.unity.modules.ai": "1.0.0",
21.     "com.unity.modules.androidjni": "1.0.0",
22.     "com.unity.modules.animation": "1.0.0",
23.     "com.unity.modules.assetbundle": "1.0.0",
24.     "com.unity.modules.audio": "1.0.0",
25.     "com.unity.modules.cloth": "1.0.0",
26.     "com.unity.modules.director": "1.0.0",
27.     "com.unity.modules.imageconversion": "1.0.0",
28.     "com.unity.modules.imgui": "1.0.0",
29.     "com.unity.modules.jsonserialize": "1.0.0",
30.     "com.unity.modules.particlesystem": "1.0.0",
31.     "com.unity.modules.physics": "1.0.0",
32.     "com.unity.modules.physics2d": "1.0.0",
33.     "com.unity.modules.screencapture": "1.0.0",
34.     "com.unity.modules.terrain": "1.0.0",
35.     "com.unity.modules.terrainphysics": "1.0.0",
36.     "com.unity.modules.tilemap": "1.0.0",
37.     "com.unity.modules.ui": "1.0.0",
38.     "com.unity.modules.uielements": "1.0.0",
39.     "com.unity.modules.umbra": "1.0.0",
40.     "com.unity.modules.unityanalytics": "1.0.0",
41.     "com.unity.modules.unitywebrequest": "1.0.0",
42.     "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
43.     "com.unity.modules.unitywebrequestaudio": "1.0.0",
44.     "com.unity.modules.unitywebrequesttexture": "1.0.0",
45.     "com.unity.modules.unitywebrequestwww": "1.0.0",
46.     "com.unity.modules.vehicles": "1.0.0",
47.     "com.unity.modules.video": "1.0.0",
48.     "com.unity.modules.vr": "1.0.0",
49.     "com.unity.modules.wind": "1.0.0",
50.     "com.unity.modules.xr": "1.0.0"
51.   }
52. }

 

I'm not going to directly answer your question, because I think you are trying to solve the wrong problem...

Why would you run one Unity instance per user? This is not going to be cost effective as you scale. Even as it is now surely 2 users connect to one server instance?

You should think about building your server in a such a way that it can support multiple 1v1 games on the same instance.

 

I'm thinking the same way. Using a single Unity instance for just 2 players wastes a lot of resources already and isn't very cost effective. Put as many players into the same instance as possible, re-use it instead of stopping and starting it, and make it somewhat dynamic so you can let more players join the same instance depending on server hardware it's hosted on and current server load.

Besides that, always use a seperated project for client and server, and remove all textures, shaders and materials from the server project.
Also play around with the player and build settings. Check if switching to Mono/IL2CPP makes any difference. Check if using incremental GC makes any difference. Check if you can disable logging or reduce it to a minimum at least. Make sure you use release builds instead of debug builds, and compile external DLLs in release mode as well.

I'm also wondering if you could replace some of your plugins/libraries with something more lightweight or custom.
Could you replace the Steamworks API for example?
If you won't ship the dedicated server files to your players later (in case you are creating a MMO where you keep the full server control for example), you could try to use Steam Web API for all important verifications instead.
And what about OdinInspector? Is it included in the build? If so, why? It seems to be an Editor extension, so it should stay there.

 

I misspoke, we have an instance of build server for two players (because it's a versus game).

I see on multiple forums, github and Discord that is the "best" solution to create a multiplayer game. But what about the links between the NetworkIdentities ? Mirror uses NetworkIdentities that must be the same on client and server, that's why Mirror project's are client and server on the same code.

That's why we done! We cleared the Shaders in cache, the pre-loaded shaders too, we moved on Mono with .NET4, we excluded the code that musn't be on server (with define symbols) and we lowered our build to 152Mb of memory. That's stiil too high but we made a great reduction! Thank you

That's a good idea, but the game isn't built to do that for now. And I really don't know how to achieve this with Playfab because the service allow us to instantiate server builds in the matchmaking but not to redirect to a running build