Page MenuHomeFeedback Tracker

feature request for ability to monitor performance hit on server by mission scripts
Closed, ResolvedPublic

Description

I created a Capture & Hold mission (cf attachments) which is great from performance point of view when testing with 2-4 players but makes a dedicated server die at 1 FPS with something like 30 players (even if players start to leave it's unrecoverable, it cannot go above 12 FPS). There are a lot of scripts in the mission but I (the mission maker) tried to avoid broadcasting too many messages (it didn't look like a network problem, the server has good upload - around 70 Mbps - and with #monitor command I saw arma server was using around 5-8 Mbps upload and something below 1 Mbps download during the mission).

Here are some ideas to help me (and others) investigate the performance issues of Arma missions:

  • the most important is to give mission makers a way to distinguish between bad dedicated arma server configuration and bad mission scripts and allow mission makers to investigate about what generates bad server FPS in their scripts
  • create a log file for the server and/or client that outputs what scripts/function names/publicvariableXXXX commands that generate most of the network load/FPS drop
  • add a new scripting command that I can use in spawned scripts/threads that outputs the impact of the thread on the server FPS (I would use this command in threads that run infinite loops and I would be able to log a message telling which thread impacted the server's FPS and how much), maybe something that makes use of the functionality of the scriptName command

If you have any ideas how to improve the performance of the dedicated server or the mission I created please share them.

When we started playing all players pings became high (something between 150-300) but we didn't have desync yet. Later we started having desyncs and server FPS dropped to 1 and I even saw 0 FPS. When most of the players left the game and something like 8 players were left, there were around 12 FPS on the server.

Here is the dedicated server configuration when the test was done:

  • the mission was not a PBO file but a mission folder
  • hardware server configuration: CPU AMD Opteron 3280 8 cores / 2.4GHz, 32GB RAM, 70 Mbps upload
  • arma 3 dedicated server executable - version 0.58.105348
  • arma 3 server configuration files:

profile file

version=1;
blood=1;
singleVoice=0;
gamma=1;
brightness=1;
difficulty="recruit";
class Difficulties
{
...
};
maxSamplesPlayed=32;
sceneComplexity=1000000;
shadowZDistance=100;
viewDistance=3800;
preferredObjectViewDistance=3200;
terrainGrid=6.25;
volumeCD=9;
volumeFX=9;
volumeSpeech=9;
volumeVoN=9;
vonRecThreshold=0.029999999;

server config file

...
motdInterval = 5;
maxPlayers = 64;
kickDuplicate = 0;
verifySignatures = 2;
voteMissionPlayers = 1;
voteThreshold = 0.33;
disableVoN = 0;
vonCodecQuality = 15;
persistent = 1;
timeStampFormat = "full";
BattlEye = 0;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";
onDifferentData = "";

network config file

language="English";
MaxMsgSend=1024;
MaxSizeNonguaranteed=64;
MinBandwidth=50000000;
MaxBandwidth=60000000;
MinErrorToSendNear=0.0001;

  • issue attachments: mpStatistics.log, ch_100_battlefields_2013_t27.Stratis {F19715}

Details

Legacy ID
4050079093
Severity
None
Resolution
Open
Reproducibility
N/A
Category
Performance

Event Timeline

d3nn16 edited Steps To Reproduce. (Show Details)Jun 3 2013, 12:12 AM
d3nn16 edited Additional Information. (Show Details)
d3nn16 set Category to Performance.
d3nn16 set Reproducibility to N/A.
d3nn16 set Severity to None.
d3nn16 set Resolution to Open.
d3nn16 set Legacy ID to 4050079093.May 7 2016, 2:23 PM
Bohemia added a subscriber: rogerx.Jun 3 2013, 12:12 AM

Tip: Your first paragraph should contain a brief summary of what you desire or what this bug is about. Especially when the bug details are lengthy.

In your current bug summary, title is "performance investigation capability" which likely means you want the ability to monitor server performance but isn't quite clear.

Since it isn't clear within the topic, the first paragraph should clear up any misconceptions but you immediately dive into reproducing the bug within the first paragraph.

So, maybe doing the following might generate more interest with this bug or feature request:

  1. Insert a beginning paragraph briefly describing the contents of the entire bug summary you've typed, so nobody is required to read the entire lengthy report to comprehend the bug.
  1. Maybe also rephrase the title to something more suitable if I'm correct such as, "Monitoring Server Load and Performance"

Good luck. ;-)

rogerx added a comment.Jun 3 2013, 6:19 PM

Tip: Can also vote for you own submitted bugs.

A well programmed program should be well documented and output plenty of debugging data.

Programs should output debug data using a command line switch to a specified debug file. (ie. -v/--verbose) Incrememting or deincrimenting debug output is also sometimes desirable, but I usually just dump everything with maximum verbose level and/or strace; and grep my way through the data.

Programs should be able to be run within a Memory Leak or Performance Monitoring analyzing tools. (ie. ltrace for linux, monitors time spent within library/function calls)

Many errors or stalls while outputting real time debug data are also indicative of performance related issues. (ie. Within one shell run the program "program.exe -v debug.log" and within another shell monitor in real time with "cat debug.log")

A lacking of proprietary or closed source, are these abilities leaving end users with only a debug log file, and not necessarily in real time. Most times, I've seen where the programmers needed to custom code such facilities in order to meet this demand.

Usually open source can readily use after market performance monitoring programs, and as such become more stable and more streamlined much faster than closed source!

MadDogX added a subscriber: MadDogX.May 7 2016, 2:23 PM

Mass closing ancient tickets with no activity for > 12 months; assume fixed or too trivial.

If this issue is still relevant in current dev build, please re-post.