The DayZ Server Performance Lab

The performance guide only says things we can stand behind, and the settings reference marks plenty of rows "unmeasured". This page is the queue between the two: the open questions, and the tests that will settle them.

One rule makes this page worth reading: for every test, the pass/fail threshold is written down before the data is collected, and it does not move afterwards. If a result lands near the line, the answer is "inconclusive, larger sample" — never a nudged threshold. We publish the outcome either way: a clean "no effect" changes the guide just as much as a positive result.

Open experiments

Does -limitFPS deliver what you ask for on Linux?

On Windows we measured that delivered rates snap to a coarse timer grid (asking for 200 delivers ~64). On Linux we have one measured point: a 200 cap delivers ~190, which fits a model where the cap is divided down to a whole-millisecond sleep target. The test: a ladder of cap values on a live Linux server, one value per scheduled restart, read from Average server FPS. Decided in advance: if 180 and 200 deliver within 2% of each other and 100 lands near 97 (clearly separated from them), the model is confirmed; if 100 collapses onto the 180/200 pair, Linux quantises like Windows and the guide's cap advice gets rewritten. The value most worth watching is 30 — the model predicts Linux delivers ~30 there, right at the engine's internal floor, where Windows delivers 16. Status: queued — designed to ride the scheduled restarts of one of our own servers, one value per restart, no player impact.

Is any cap value actually better than another?

The engine's fastest internal schedule runs 30 times a second and resets its own clock each time it fires, so the achieved internal rate may depend on how the frame rate divides into 30 — a sawtooth in which some cap values sit better than others. The test needs an instrument that counts the internal schedule directly, which does not exist yet; building it is the hard part. Decided in advance: a peak-to-trough spread of 15% or more across the ladder makes specific cap values recommendable and the guide gains a short table; a flat rate within ±5% means no value above the floor beats another, and the guide says so as a measured null. Status: instrument design. This blocks any cap-value recommendation, which is why the guide refuses to give one.

Does lowering networkRangeFar actually help?

The one config lever on the replication set — and a combat change, as the guide explains. Guides promise 15–20% bandwidth savings with no source. The test: two sister servers alternate 1000 vs 800 by session for at least two weeks, comparing frame times at matched player counts, with an in-game check that the change is actually live. Decided in advance: a 10%+ improvement at high population publishes as a measured benefit — in the same paragraph as the measured combat cost; an interval including zero publishes as "no measurable upside" and the guide keeps its recommendation with a measured reason. Status: needs a populated fleet willing to run the alternation — the combat-visibility disclosure makes this a real ask, and we will not run it quietly.

Does multithreadedReplication do anything?

Nobody has published a measurement. On an empty test server the switch changed nothing observable — which proves nothing, because there was no network work to move. The test: first make the switch observable (thread census, per-thread CPU) under synthetic load, then alternate by session on a populated server. Decided in advance: a 10%+ frame-time move in either direction gets published with its direction; an observable arm with no move publishes as a real bound; an arm that changes nothing observable publishes as exactly that, with no bound claimed. Status: open; the populated half waits on adoption.

Is simulatedPlayersBatch really a cap on real players?

We verified the default (−1: every player, every pass) in the server program, and the guide warns that writing a number is a cap. The real-player half of that is still an inference. The test: on a populated server, alternate no-key vs a deliberately low value, measuring per-player service rate. Decided in advance: if the low-value arm's aggregate service rate drops toward the predicted fraction, the cap framing is confirmed as measured; if the rate does not move, the key does nothing observable to real players either and the guide's warning gets rewritten to say so. Status: blocked on a populated server running current instrumentation.

Do zombie counts cost anything at real population?

With nobody nearby, spawned infected consumed no measurable simulation time — the engine only fully simulates what someone is close to. But that was measured on an empty server, and "counts are not cost" deserves a test where it could actually fail. The test: halve ZombieMaxCount on a populated server, alternating by session at matched player counts. Decided in advance: under 3% frame-time change confirms the guide's mechanism sentence as measured at population; 10% or more retracts it. Status: needs an operator willing to run the alternation.

Do cleanup passes ever cost enough to feel?

The reference marks every CleanupLifetime* performance effect unmeasured. The engine has free, config-only logging that times its own cleanup passes — nobody seems to have read it. The test: enable the engine's economy log flags, then sweep one lifetime value from default to one quarter with a large persistence file, reading pass durations directly. Decided in advance: any single pass at 250 ms or longer earns the guide a freeze-risk caveat even if averages never move; a frame-time difference under 2% between arms confirms "no faster server from shortening them" as measured. Status: queued — cheapest experiment on this page.

Do the login-queue defaults actually protect a restart?

Bohemia says the low concurrent-login number prevents a performance drop when everyone reconnects at once. That is their claim, and the current instrumentation cannot even see the queue. The test: alternate the concurrent value between 5 and 25 across wipe-night restarts, comparing the first five minutes of frame times — after the queue becomes observable, so a "no difference" can be trusted. Decided in advance: 25%+ worse with the default means the default is harmful and the guide says to raise it; 25%+ better confirms Bohemia's rationale as measured; within 10% publishes as "no measurable difference". Status: blocked on instrumentation, then a wipe night.

What decides how badly a server degrades?

The biggest open question on the guide: servers matched on population and restart cycle still land anywhere from untouched to severely degraded across a long session. Mod-hook plumbing is measured and far too cheap to explain it. The test: regress degradation amplitude against candidate explanations (mod roster, entity churn, timer counts, hardware class, wipe age) across enough adopted servers. Decided in advance: any single factor explaining 60%+ of the spread earns a conditional recommendation ("on servers with X, expect Y"); if every candidate explains under 20%, the guide says we looked and found nothing — which is also worth knowing. Status: needs more servers reporting; this is the question the optional Sentinel mod exists to answer.

Does -freezeCheck behave the same on Linux?

Everything measured about it (dump timing, the forced crash that never fires) is from a Windows server with one kind of induced freeze. Many production servers run Linux. The test: induce freezes of known lengths on a Linux test server, in more than one way, and check the dump count against what a known freeze length predicts. Decided in advance: if Linux actually terminates a wedged server at the five-minute mark, the guide's watchdog advice becomes conditional and says so; if Linux reproduces the Windows behaviour, the external-watchdog recommendation is measured rather than prudent. Status: needs a maintenance window on a test box.

Why does Windows deliver those exact cap values?

Every delivered period on Windows is an exact whole multiple of the ~15.6 ms scheduler tick — seven values tested, seven exact multiples. But the rule mapping a requested value to its tick count is still unknown: three candidate formulas each fit part of the data and were killed by the rest — including one that fit five points perfectly and failed the two values it had never seen. We are saying that publicly because it is the whole method in miniature: a formula that survives only the data it was built on is not a finding. Status: open; needs inspection of the server program's sleep path, not more curve-fitting.

When an experiment lands, its row moves: the result goes into the settings reference as evidence, the guide changes only if the result changes the advice, and anything we previously got wrong goes in the guide's corrections log.