1. Docs
  2. Server Configuration for Performance

Server Configuration for Performance

This page is for server owners who want a sane serverDZ.cfg, launch line and economy settings without reading an engineering paper. Copy the blocks below, then read the short notes on what each line does. It will not make a slow host fast or fix a mod that freezes the server — but it will stop you chasing "optimisations" that do nothing, and it will turn on the cheap logs that tell you where the problem actually is.

This page deliberately says less than we know. Every setting — including the ones we refuse to recommend — is catalogued with its evidence state in the settings reference, and the open questions, with the tests that will settle them, are on the performance lab.

Copy this into serverDZ.cfg

Fill in the identity lines and the mission template; leave the rest as written unless you have a specific reason.

// ---- Identity and access (fill these in) ----
hostname = "My Server Name";
password = "";
passwordAdmin = "CHANGE-ME";
maxPlayers = 60;
verifySignatures = 2;
forceSameBuild = 1;
instanceId = 1;

// ---- Login queue (leave) ----
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;

// ---- Persistence (leave) ----
storageAutoFix = 1;

// ---- Logging: keep these on ----
logAverageFps = 1;
logMemory = 1;
logFile = "server_console.log";
adminLogPlayerHitsOnly = 0;
adminLogPlacement = 1;
adminLogBuildActions = 1;
adminLogPlayerList = 1;

// Deliberately NOT set: networkRangeClose / Near / Far / DistantEffect,
// simulatedPlayersBatch, multithreadedReplication,
// networkObjectBatchCompute / SendCreate / SendDelete. See the notes below.

// ---- Map-specific (fill this in too): your map's mission template ----
// The value below is vanilla Chernarus. Livonia, Deer Isle, Namalsk, Sakhal and
// every modded map need their own template name - pasting this line unchanged
// boots the wrong map.
class Missions
{
    class DayZ
    {
        template = "dayzOffline.chernarusplus";
    };
};

Copy this into your launch line

DayZServer_x64.exe -config=serverDZ.cfg -port=2302 -profiles=profiles -BEpath=battleye
    -mod=@Mod1;@Mod2 -serverMod=@ServerOnlyMod -doLogs -adminLog -freezeCheck -cpuCount=8

-cpuCount is left in because everyone uses it and we have seen no harm from it — but it does not control the thread pool most guides say it controls; see the note below before you spend any time tuning it. There is deliberately no -limitFPS here either — see the note below for the one situation where you want it.

Optional — see what your server is actually doing

If you want the questions above answered by a page instead of a guess, add one more mod to the launch line:

-serverMod=@SentinelEnforcer

It is a server-side mod — players download nothing. It reports your server's frame health, how it behaves over each restart cycle, and what changed (mods, settings) to your dayz.fyi dashboard, so "is my server slow, and since when" has an answer you can look at. Opt-in; install steps are on the Sentinel Enforcer page.

Economy values people are told to cut (db/globals.xml)

These are the values Bohemia ships — we checked them against an untouched install. Change them for the gameplay you want; the notes below explain why they are not the performance levers guides treat them as.

<var name="ZombieMaxCount"              type="0" value="1000"/>
<var name="AnimalMaxCount"              type="0" value="200"/>
<var name="CleanupLifetimeDeadPlayer"   type="0" value="3600"/>
<var name="CleanupLifetimeDeadInfected" type="0" value="330"/>
<var name="CleanupLifetimeDeadAnimal"   type="0" value="1200"/>
<var name="CleanupLifetimeRuined"       type="0" value="330"/>

Restart schedule

Not a config line — set it in your host panel or scheduler.

Some busy servers develop a measurable slowdown across a long session, and restarting clears it. Others — matched for player count and restart cycle — run whole cycles with nothing measurable happening. A quiet server barely degrades at all: the slowdown needs a decent number of players on before it appears in the first place. We have measured both patterns on real fleets, and nothing we have measured so far predicts which one a given server will be. That is why the only restart schedule worth having is one read off your own server, not copied from a guide.

We are deliberately not giving you an hour figure. How fast a server bogs down turns out to be specific to the server. Two servers with the same player cap and the same restart cycle can behave completely differently — one falls off a cliff partway through a cycle, the other runs the whole cycle with nothing measurable happening. An hour copied from someone else's guide is about as likely to cost you a restart you never needed as to save you one.

Find your own number instead. Plan on at least ten busy sessions — a week or two for most servers — noting your server's frame rate early in a cycle and again late in the same cycle at a similar player count. (We measured how noisy this comparison is on real servers: a couple of evenings is not enough to tell a real slowdown from ordinary session-to-session swing.) If late figures keep coming in well down on the early ones, your restart is coming too late — move it earlier until the drop stops appearing. If they keep looking the same, you have no reason to restart more often than you already do.

One more thing we measured while checking that: the slowdown is usually not a gentle drift. On the servers we watched, the typical session barely moves, and what stands out is the occasional session that ends far slower than it started. So judge on the pattern across your sessions, not on any single evening — one clean evening does not clear you, and one bad one does not condemn you.

Two things to know while you do that. Check it on an aged map, not a fresh one — a freshly wiped server can run clean at full population and then develop the same slowdown weeks later, so a test run just after a wipe can tell you everything is fine when it is not. And restarting does not reset everything: there is a slower drift that builds across a whole wipe and survives restarts, which is why a server can feel worse in week four than week one on an unchanged schedule.

A busy server and a long session are what the slowdown needs in order to appear — but among servers matched on both, outcomes still range from untouched to severely degraded, and what separates them is an open question we are actively measuring. One thing we have measured: the per-event plumbing that mods hook into the server is far too cheap to explain it, so counting your mods will not answer the question either. That is exactly why you have to watch your own server.

What each line does and why it matters

hostname, password, passwordAdmin — your server's name, join password (empty = public) and the admin login password. Change the admin password; it is the one line here that matters for security rather than performance.

maxPlayers — the player cap. This is the one setting with a straightforward effect on load: more players, more work, and the late-session slowdown on busy servers comes with population. If a server cannot hold its peak, lowering the cap works — not by making the server faster at any given player count, but by stopping it from reaching the counts where it struggles.

verifySignatures = 2, forceSameBuild = 1 — clients must run signed, matching files. Leave on.

instanceId — identifies this server's persistence folder. Unique per server on a box.

loginQueueConcurrentPlayers = 5, loginQueueMaxPlayers = 500 — how many players are processed into the world at once, and how many may wait. These are the defaults and we have no reason to change them. (Bohemia's stated reason for the low concurrent number is to protect the server during the login rush after a restart — that is their claim, not something we have measured.)

storageAutoFix = 1 — Bohemia describes this as repairing corrupted persistence files at boot rather than failing; we have confirmed the server program reads the setting at boot (checked on Windows) but have not put the repair itself to the test. Leave it on. One thing we did verify: there is no "save interval" key to tune in this file — saving is handled by the engine and the economy.

networkRangeClose/Near/Far/DistantEffect — how far around each player the server bothers to send things. Close covers containers with items in them, Near covers loose inventory items, Far covers everything that is not an inventory item, and DistantEffect is a separate, much larger bubble used for sound. We leave all four lines out of the block. Guides paste them with numbers labelled as "the defaults", but the only source for those numbers is documentation we have caught publishing sample values as defaults before — and there is no reason to write these keys at all unless you intend to change them, which the next paragraph is about.

⚠️ networkRangeFar is the one people reach for, and it is far more dangerous than the guides that recommend it suggest. "Everything that is not an inventory item" includes vehicles, buildings and infected — but it also includes other players, and bullets in flight. Lowering it is therefore not a scenery or draw-distance tweak: it changes how far away your players can see each other and be shot at. Reduce it enough and you have changed how combat works on your server.

And the upside is unproven. Sending each player fewer distant things ought to be less work, but we have never measured how much, and the bandwidth percentages quoted around this setting come with no source. The reassurance that usually travels with them — that players rarely engage beyond 600–700 m, so nothing of value is lost — is backwards: those rare long-range engagements are exactly what the setting deletes, and the players who notice will be the ones aiming. So it trades a real, understood cost against an unmeasured benefit — which is not a trade we will recommend. If you experiment anyway, change this one line alone, keep the reduction small, and judge it across several sessions.

Distant gunfire is networkRangeDistantEffect, not networkRangeFar. Most guides attribute faraway gunshot sounds to the wrong key. Leave networkRangeDistantEffect at its default.

⚠️ guaranteedUpdates — we have taken this one out of the block, and you can take it out of yours. It appears in Bohemia's example config and in nearly every guide, usually described as having "one valid value" — some go further and describe what it costs, advising busy servers to turn it off. We went looking for the code that reads it and could not find any — the name does not appear anywhere in the Windows server program or the Linux one, while every setting on this page that is read appears in an obvious list right next to its neighbours. Leaving the line in your config is harmless; changing it does nothing; and any guide explaining what it "costs" is describing a setting the server never reads.

logAverageFps = 1 (needs -doLogs) — writes a server-FPS line to the log every second. Two things to know when you read it.

First, it is a relative number, not a score. There is no single figure that means "healthy". What a working server reads depends on your hardware, your mods and how many players are on, and the range is enormous — a quiet server can report numbers so high they look like a typo, and that is normal. Compare your server against itself: note what it reads when quiet and at your busiest hour, and treat those as your baseline. What matters afterwards is movement away from your own baseline, not distance from a number in someone else's guide, including ours.

Second, if an empty server reports a low, flat number that barely moves, that is usually a cap, not a healthy idle. A quiet server pinned at a steady figure is telling you there is a -limitFPS on your launch line. Do not expect that figure to equal the cap you set — a cap is a target the server approaches, not a number it hits. Our own Linux servers capped at 200 sit at about 190, and on Windows the delivered figure can be far below the cap (see the -limitFPS note below). So identify a cap by the flatness, not by recognising a familiar number in the log: a genuinely idle, uncapped server does not settle on a steady figure at all.

logMemory = 1 — writes memory use to the log. Together with the other log* lines it cost nothing we could measure on an idle test server, so keep it on. A memory figure is useful context when you look back at a bad night — though whether memory growth actually tracks the slowdown is something we have not established, so read it as context rather than a verdict.

logFile — keeps the console output on disk so you can look back at a bad night. ⚠️ It grows and nothing trims it — even a quiet test server of ours reached nearly 19 MB. Sweep old copies out on a schedule, or one day it is the reason your disk is full.

adminLog* (with -adminLog) — writes the admin log: hits, placements, building, a player list every few minutes. This is what you need to line up player reports with what the server was doing. See Reading DayZ admin logs.

Why simulatedPlayersBatch, multithreadedReplication and the networkObjectBatch* lines are not in the block — these are the "optimisation" values that get copied from guide to guide. The batch values people paste (1000, 10, 10) trace to the same documentation whose "defaults" have been wrong before; nobody has shown the lines to change anything, and we could not verify the claimed defaults against the server program itself. Leave the lines out.

⚠️ simulatedPlayersBatch is the exception, and it works the opposite way round to how it is described. Guides tell you to "raise it to 30" for a stronger CPU. But left out of your config entirely, the server already services every player every time round — so writing a number in is a limit, not an increase, and on a server with more players than that number it is a restriction you did not mean to apply. Nobody has measured what that costs, including us. Leave the line out. (The every-player-every-pass behaviour is verified against the Windows server program; we have not confirmed the default on Linux.)

multithreadedReplication — nobody, including us, has published a measurement of what it does to a real server. We leave it out; if you experiment, change only that one line and judge it over several sessions.

-doLogs -adminLog — turn on the logs above and the admin log. Keep them. The log* lines cost nothing we could measure on an idle test server; the admin log's cost on a full server is something we have not measured, and we recommend it anyway as a deliberate choice — it is the record you will want when something goes wrong.

-freezeCheck — a freeze detector. Keep it, but know what it does and what it does not do. When the server stops responding it writes a crash dump within about ten seconds, named with a FROZEN_ prefix, and keeps writing one every ten seconds or so while the freeze lasts. Those dumps are the useful part: they are a snapshot of the server at the moment it stopped, which is exactly what you need if you ever want the problem diagnosed. (We measured this behaviour on a Windows server with one kind of induced freeze; we have not repeated it on Linux.)

⚠️ Do not treat it as something that will restart a stuck server. After about five minutes it marks the server for a forced crash — but in testing, a server whose main thread was genuinely wedged carried on sitting there, and only exited once it started responding again. If you need a hung server brought back automatically, you need a separate watchdog — something outside the game that checks the server is answering and restarts it if not. Most host panels can do this; so can a small scheduled script.

⚠️ -cpuCount — nearly every guide tells you to match it to the cores your machine has; some publish whole tables of recommended values per CPU model. We tested it, and it does not do what those tables assume.

The server does its background work on a pool of helper threads. What decides how many of those it makes is not -cpuCount — it is a setting called maxcores, in a small file named dayzsetting.xml that sits beside the server program. We raised maxcores and the server made more helper threads and stopped complaining that it had too few. We set -cpuCount instead, confirmed the server had received it, and it made none, and the same complaint kept appearing in the log.

Keep the line if you already have it — we have seen no sign it costs anything, and we have only shown that it does not size that thread pool, not that it does nothing at all. What we would say instead: if you are chasing this, the setting to look at is maxcores, and the file as shipped is set to two cores with one reserved, which leaves a single helper thread. Whether giving the server more helpers actually improves anything a player would feel is unmeasured — we tried, and on an empty test server there was nothing to measure. Change it only as a deliberate experiment, one thing at a time.

(Tested on a Windows server. We have not repeated it on Linux.)

-limitFPS — caps how many frames per second the server runs. It is a way to share a machine, not a way to speed a server up.

Most of what a DayZ server does is not driven by your frame rate. Player characters, the pass that streams the world to each player, the economy, weather, hunger and thirst all run on their own schedules — the fastest of them around thirty times a second — and several of them work from elapsed time, so the result is the same whether they are visited often or rarely. (We verified these schedules in the Windows server program.) Running more frames per second does not make those schedules run faster, which is why the frame-rate arithmetic found in most tuning guides — "more fps means the server processes X more objects per second" — does not predict what a cap actually does.

What more frames do buy is notice time: the server checks for newly arrived player packets once per frame, so a faster server starts reacting to them sooner. That effect is real, but it is small beside the internet round trip it sits inside, and we have not measured it.

Keep the delivered rate above about 30. The engine's fastest internal schedules run thirty times a second; a server delivering fewer frames than that cannot keep their pace. What that feels like in-game is not something we have measured — but there is no upside to running under the engine's own tempo, so stay clear of it.

What happens if you leave it unset: the server runs its loop as fast as the machine allows. While players are on, that is what you want. While it is empty, expect it to keep running flat out — tens of thousands of frames a second, one CPU core fully busy producing nothing. That idle spin is the whole cost of leaving it off. It does not slow anything down; it just occupies a core.

So set it only if something else needs that core:

  • you run more than one game server on the same machine;
  • your host meters, throttles or bills CPU, or you share the box with other tenants;
  • something on the machine kills processes that sit at 100%;
  • you care about power, heat or noise on hardware you own.

On a dedicated machine with cores to spare, leave it off — the spinning core costs you nothing you were using, and your players get the best the box can give.

If you do set it, judge it by what is delivered, not what you asked for. Watch Average server FPS in your log afterwards to see what your server actually delivers, because a cap is a target rather than a guarantee.

⚠️ On Windows, the value you ask for is not the value you get — and the gap is large. We measured this on a Windows server across seven cap values: the delivered rate snaps to a coarse grid set by the operating system's timer, not to your number. Asking for 200, 180 or 100 all delivered about 64. Asking for 60 delivered about 32 — sitting almost on the 30 floor rather than comfortably above it. Asking for 30 delivered about 16, half the floor the warning above is about. (Our Linux servers deliver close to the requested value — a 200 cap sits at about 190 — so this is specifically a Windows behaviour.) The rule that works on either platform: after you set a cap, read Average server FPS in your log and trust that figure over the number on your launch line. If the delivered figure is at or below the mid-30s, raise the cap until it is clearly not.

What we cannot tell you yet, and will not guess at: whether one cap value is meaningfully better than another above that floor. There is reason to think the cap and the server's internal schedules interact, so that some values sit better than others — but we have not measured it, and we would rather say so than hand you a number dressed up as a finding. If you want a starting point, anything in the low hundreds keeps the delivered rate comfortably clear of the floor on both platforms — just remember that on Windows the figure you actually get from a value like that is about 64, and that is fine.

⚠️ Never set the cap from a bad reading. If your busy figure is already low, a cap set just above it stays in force after whatever caused the low reading goes away — the server will not run faster than the cap even once it could. A low busy figure is a problem to diagnose, not a number to lock in — start with the guides at the bottom of this page.

ZombieMaxCount, AnimalMaxCount — caps on how many infected and animals exist. More zombies in the config does not slow the server by itself — zombies near players do, because the engine only fully simulates what someone is close to. Cutting the count is a gameplay change, not a performance fix.

CleanupLifetime* — how long dead bodies and ruined items stay before the economy removes them. Some guides recommend shortening these for performance; nobody has measured that effect, including us. Set them for the gameplay you want — a tidier map is a real reason, a faster server is a hope.

If player gameplay issues are still being reported

  • Work out which problem it is first — "lag" means at least four different things, and most are not the server: How DayZ multiplayer actually works.
  • One player rubber-banding while everyone else is fine is almost always their connection: the lag-report triage guide has the homework to send them.
  • Everyone freezing for a second at once, at random, is usually a mod — remove mods one at a time across restarts until it stops. No config line fixes that.

Corrections log

We test what we publish, and when a test proves us wrong we correct the page and say so here — that is the deal that makes the rest of the page worth trusting.

  • 2026-08-27 — restart guidance rebuilt on what we measured (some busy servers degrade, matched others do not) instead of a universal busier-restart-more rule; the networkRange* lines removed from the paste block (their "defaults" trace only to documentation we have caught being wrong about defaults); the unmeasured performance promise removed from CleanupLifetime*; vendor claims now attributed to Bohemia rather than restated as our own.
  • 2026-08-26 — the "exactly 60 or exactly 200" cap fingerprint corrected (a 200-capped server of ours reads about 190); measured that Windows caps deliver far below their nominal value; confirmed guaranteedUpdates is absent from the Linux server program as well; "a few busy evenings" replaced with a measured horizon of at least ten busy sessions.
  • 2026-08-25 — retracted our own -cpuCount core-matching advice (maxcores sizes the helper pool); removed guaranteedUpdates from the block (not read by the server); corrected the simulatedPlayersBatch framing (a written value is a cap, not an increase); corrected distant gunfire to networkRangeDistantEffect; dropped unsourced restart-hour figures.
  • 2026-08-24 — retracted an objects-per-frame arithmetic that was wrong twice and an idle-fps self-contradiction; reframed -limitFPS as machine-sharing rather than performance.