How to Improve Arma Reforger Server Performance and Reduce Lag
Read your server’s -logStats line, work out whether the simulation or the network is the bottleneck, and fix the few settings that really cause lag instead of changing everything at once.
If server FPS sits well below the cap during load, the simulation cannot keep up. That is usually CPU work from AI, players, vehicles, projectiles or scripts.
If FPS holds at the cap but players still warp or see pop-in, look at streaming and replication: networkViewDistance, -nds, budgets, connection quality and server location.
Conflict’s base building, supply lines and persistent AI logistics create sustained load that a shorter Combat Ops run often does not. Game Master can be much lighter until the session fills with spawned content.
Reforger tuning is easiest when each change has a reason. Keep a baseline, change one setting, and check if FPS, frame-time spikes or replication symptoms actually improve.
What lag means on an Arma Reforger server
On a Reforger server, “lag” can mean three different things, and only one of them is the client PC. Server FPS is how fast the dedicated server advances the simulation. Client FPS is the player’s own frame rate and can be poor even when the server is healthy. Ping is travel time between player and server; it affects delay, but high ping is not the same thing as a slow simulation.
The useful way to think about server FPS is frame-time budget: 1000 / FPS. At 60 FPS, each update has about 16.7 ms. At 120 FPS, it has about 8.3 ms. At 30 FPS, it has about 33.3 ms. If a busy frame takes longer than the budget, server FPS drops. That is why the max frame time in the log matters so much: big spikes mean the server is occasionally missing its deadline even if the average looks passable.
That gives you two broad fault types:
- Simulation bound: server FPS drops below the
-maxFPScap, often with rising frame-time max. This points to CPU work from AI, vehicles, projectiles, players or mod scripts. - Replication bound: server FPS stays at the cap, but players see rubber-banding, AI or vehicles warping, and distant pop-in. This points to too much streaming range, aggressive network budgets, poor connection quality or a bad location choice.
Start by deciding which of those two you have. It stops you cutting AI for a problem that is really network streaming, or lowering distance for a problem that is really AI CPU.
Measure first with -logStats
Enable logging before you tune anything. A single line every few seconds is enough to tell you if the server is choking on simulation work or if replication is the real bottleneck.
-maxFPS 60 -logStats 10000 FPS: 60.0, frame time (avg: 16.7 ms, min: 9.3 ms, max: 23.7 ms), Mem: 3291106 kB, Player: 2, AI: 104, Veh: 0 (17), Proj (S: 12, M: 0, G: 0 | 12), RplItemsS: 410, RplItemsC0: 17068
Take a baseline when the server is actually under strain: a full or near-full session, late enough in the round that bases, vehicles, AI and mods have had time to do work. A fresh restart with a handful of players tells you very little.
| Field | What it tells you | What a bad trend points to |
|---|---|---|
| FPS | Current server FPS. | Below your -maxFPS cap under load means the simulation is CPU bound. |
| frame time avg/min/max | How long each update took. | High max spikes during joins, teleports, saves or firefights mean bursty work the server cannot finish inside the frame budget. |
| Mem | Server memory as reported internally. | A steady rise across long sessions can point to persistence, mod or navmesh pressure, but this figure is only an approximation and not a perfect match for the OS view. |
| Player | Current players. | Use it as context. Compare logs from similar player counts, not random moments. |
| AI | AI currently spawned. | If FPS drops as AI rises, AI simulation is your first suspect. |
| Veh | Vehicle activity, with the spawned count in parentheses. | Stutters that line up with lots of active vehicles suggest physics and replication load. |
| Proj | Shells, missiles, grenades and total projectiles. | Spikes during large fights point to combat simulation load, not just player count. |
| RplItemsS | Dynamic streams on the server. | If this climbs with object-heavy sessions, distance and replication scope are likely too wide. |
| RplItemsC0 | Streams open to the client. | If this stays high while FPS still holds the cap, players’ warping and pop-in are more likely replication or network issues than raw simulation speed. |
There is no single “bad” number that applies to every server. The useful question is what changed between a smooth session and a bad one.
Setting 1: cap the server properly with -maxFPS
This is the first fix because it stops the server wasting CPU. Bohemia heavily recommends -maxFPS in the 60..120 range; without it, the server can try to use all available resources. That often makes performance less predictable, not more.
-maxFPS 60 is a sensible starting point. It gives each frame a 16.7 ms budget, which is much easier to hold than 8.3 ms at 120. The trade-off is simple: a lower cap means lower maximum simulation update rate, but a stable cap is far better than chasing a higher one the server cannot sustain.
If the server already sits well below the cap during busy moments, raising the cap will not help. That only shortens the time budget further. In that case you are CPU bound and need to cut work: AI, vehicles, projectiles, players or mod overhead. If the change helped, FPS will stick to the cap more often and frame-time max spikes will shrink.
Setting 2: cut AI work when FPS falls as AI rises
AI is the first thing to examine when Reforger slows down as a session grows. AI thinking, pathing and ticking are steady simulation work, so they hurt the main update loop directly. In Conflict, that can become sustained background load rather than short bursts.
"operating": {
"aiLimit": -1,
"disableAI": false
} Those are the defaults: -1 means no AI limit. The same controls exist as startup parameters, and -aiLimit overrides the config value. A value of 0 or below disables AI completely, so pick a real number for scenarios that need bots.
-aiLimit <number> -disableAI -aiPartialSim 4
aiLimit / -aiLimit: this sets the top limit of spawned AI. If your logs show FPS collapsing when AI count rises, limiting AI is often the cleanest fix. It saves CPU by preventing new AI from entering the world, but the trade-off is obvious: some scenarios lose pressure, ambience or even key logic if they depend on bots.
disableAI / -disableAI: for a pure PvP server, disabling AI completely can remove a large block of server work because AIWorld is not initialised or ticked. Do not use this on scenarios that expect AI; it can break the experience rather than optimise it.
-aiPartialSim: this divides simulable AI into batches. With the default 4, not every AI is processed in the same instant. That does not remove total AI cost, but it spreads the work across updates. Leave it at the default unless you are deliberately testing AI load.
disableNavmeshStreaming: this is a memory-for-performance swap. Loading the whole navmesh into RAM can give slightly better server performance and AI reaction times because the server is not streaming navmesh data on demand. The cost is a bigger memory footprint, potentially up to hundreds of MB depending on terrain. Watch Mem and only treat this as worthwhile if AI is the problem and memory headroom is fine.
As a rule, Conflict tends to punish AI-heavy setups more than Combat Ops, while Game Master can start light and then become heavy as admins spawn units. If AI numbers line up with falling FPS, this is the right section to tune first.
Setting 3: fix view distance and network distance before touching obscure network knobs
If server FPS stays at the cap but players still complain about warping, late spawns and pop-in, look at what the server is trying to stream to each client.
"gameProperties": {
"serverMaxViewDistance": 2500,
"serverMinGrassDistance": 50,
"networkViewDistance": 1000
} serverMaxViewDistance controls how far players can see. networkViewDistance controls the maximum range at which replicated entities are streamed over the network. Those are not the same thing. The defaults are 1600 m for view distance and 1500 m for network distance. If you raise the network distance past what players can see, the server spends CPU and bandwidth streaming things nobody can use yet.
Bohemia’s own example config uses 2500 for view distance and 1000 for network distance. That is the right idea: keep the networked world tighter than the visible horizon. This works because the amount of area covered grows with the square of distance. Cutting the streamed radius from 1500 to 1000 reduces the streamed area to about 44% of the old area, so the server has far fewer distant entities to consider for each client.
The trade-off is player awareness. Set it too low and people will notice pop-in or vehicles appearing late. If it helped, you should see fewer reports of rubber-banding with FPS still at the cap, and RplItemsC0 should come down in busy areas.
serverMinGrassDistance is not a main performance lever. At 0, the server does not force a grass distance on clients. Forcing grass distance is mostly about visual consistency and fairness, not fixing server-side lag.
If the simulation is healthy but remote players still feel delayed, check how server location affects ping before blaming your server settings.
Settings 4 and 5: players, joins, validation and mods
Player slots and join behaviour
maxPlayers defaults to 64 and can go up to 128, but more slots mean more movement, inventory, replication and join traffic. Bohemia’s own example config uses 32. If your logs show the server struggling long before the lobby is full, lowering slots is a cleaner fix than hoping the hardware will cope later.
joinQueue.maxSize (default 0, which turns it off, up to 50) lets players wait in line for a free slot. It does not reduce load by itself, but it means you can set maxPlayers to what the server really handles without turning people away at peak time.
Keep fastValidation set to true. This matters on any public server. With it enabled, the server exchanges the minimum data needed to validate a joining client. If you disable it, the server sends extra data for every replicated entity and component when someone connects, making each join much heavier. That is exactly the kind of setting that turns a late-session join into a server-wide hitch.
Mods
Every listed mod is required by clients and auto-downloaded on join. The server cost is not just download time: mods can add scripted systems, persistent objects, AI logic, vehicles and extra replicated content. Treat each mod as potential CPU, memory and bandwidth load.
Do not add or remove several at once if you are chasing lag. Change one mod, then compare -logStats at the same player count and session stage. If a problem started after a content pack was introduced, remove the newest suspect first. Use -addonsVerify to check installed addons and -addonsRepair to repair corrupted ones automatically, and keep versions current after game updates.
If you need the exact file locations, startup syntax or config layout while doing that, use our Arma Reforger dedicated server setup guide.
Advanced network tuning: only after the basics are right
If settings 1 to 5 did not solve it, then it is time for the deeper network levers. These mostly trade replication smoothness against per-tick work and bandwidth. Do not touch several together or you will not know which one changed the symptom. First, the matrix compares every lever in this guide by what it saves.
| Lever | Server CPU | Network traffic | Memory |
|---|---|---|---|
| -maxFPS cap (60–120) | Yes | – | – |
| Lower aiLimit, or disableAI for PvP | Yes | Partly | – |
| Lower networkViewDistance | Partly | Yes | – |
| Lower -nds diameter | Yes | Partly | – |
| Fewer maxPlayers | Yes | Yes | Partly |
| Keep fastValidation true | Partly | Yes | – |
| disableNavmeshStreaming | Partly | – | No |
| Fewer mods | Partly | Partly | Partly |
| Lever | Why it works | Too high | Too low |
|---|---|---|---|
-nds | Sets Network Dynamic Simulation diameter in cells. Higher values stream a wider networked world per client. | More replication work, lower server performance. | Visible pop-in or entities arriving too late. |
-nwkResolution | Sets the spatial map cell size, from 100 to 1000 m. Bohemia’s advice for a long view range is a high resolution with a small -nds diameter. | Bigger cells give a wider networked range but more pop-in. | Smaller cells mean less pop-in but a shorter networked view range. |
-staggeringBudget | Limits how many stationary cells are processed per tick. | Big performance drops when players spawn or teleport. | Entities take too long to stream in. |
-streamingBudget | Global streaming budget shared between connections. | Big per-tick load and join or teleport hitches. | Pop-in and delayed replication. |
-streamsDelta | Limits streams opened for a client per tick. | Too many streams opened at once for clients on slower connections. | Slow catch-up for clients on move or on join. |
Leave the threading parameters alone unless you understand your machine’s CPU layout. The defaults are usually the safer choice, and -singleThreadedUpdate is a diagnostic switch, not a performance tweak. Do not use it to try to fix lag.
Saves, restarts and long sessions
"persistence": {
"autoSaveInterval": 10,
"saveRetention": 10
},
"operating": {
"playerSaveTime": 120
} Saves trade hitch frequency against rollback risk. The defaults are a session save every 10 minutes and a player save every 120 seconds. A shorter autoSaveInterval means more frequent saves and more chances for small pauses, but less lost progress after a crash. A longer interval reduces save hitches, but players lose more if the session dies. playerSaveTime does the same for player state, and higher saveRetention keeps more save history at the cost of disk space.
If slowdown builds late in long Conflict sessions, do not ignore the simple answer: restart between sessions. Persistent bases, supply chains, AI logistics and modded systems all accumulate work. A scheduled restart is often worth the short interruption because it resets the world before creeping load turns into a bad evening for everyone.
-autoreload can reload the scenario when the session ends, while -autoshutdown helps the server shut down correctly so your service can restart it cleanly after failure or on schedule.
Symptom, likely cause and the first fix to try
| Symptom | Likely cause | First fix |
|---|---|---|
| FPS below the cap and AI count is high | Simulation is CPU bound by AI work | Lower aiLimit, use -disableAI for pure PvP, or review AI-heavy scenario design |
| FPS below the cap during big fights with lots of vehicles or projectiles | Combat simulation load | Keep -maxFPS sensible, reduce extra scripted content, and review vehicle or AI density rather than raising the cap |
| FPS holds at the cap but vehicles warp or players rubber-band | Replication or connection bottleneck | Lower networkViewDistance first, then review -nds and streaming budgets |
| Distant objects or units pop in while FPS is fine | Streaming range or budgets are too tight | Check networkViewDistance, then tune -nds, -nwkResolution and budgets carefully |
| Sharp lag spikes when many players spawn, teleport or join | Streaming budgets set too high, or heavy join validation | Keep fastValidation true, then lower -staggeringBudget or -streamingBudget a step |
| Lag starts only after adding mods | One or more mods added script, AI or persistence overhead | Remove or disable one mod at a time and compare -logStats against your baseline |
| Server slows down late in a long Conflict session | Persistent world accumulation | Schedule restarts between sessions and review AI, building and object-heavy mods |
| One player lags badly but others are fine | That player’s route, ping or local connection | Check the player’s region and connection rather than changing whole-server simulation settings |
| Server browser shows the wrong player count | Lobby synchronisation, not performance | Make sure lobbyPlayerSynchronise is left at its default of true |
| Clients fail validation or addon problems appear after updates | Corrupted or mismatched addons | Run -addonsVerify or -addonsRepair and make sure the mod set is current |
Tune it more, or move to a stronger plan?
If you are deciding between more tuning and different hardware, think in terms of the bottleneck you actually found. A CPU-bound Conflict server and a replication-bound crossplay server do not need the same answer. For a quick refresher on plan choice, read how game server hardware requirements work. For scale, Bohemia’s own Docker example gives the server 4 CPU cores and 6 GB of memory; treat that as a sensible example, not a guarantee for heavy modded Conflict.
| What you are seeing | Tune first | Consider upgrading when |
|---|---|---|
| FPS often drops below the cap in normal peak play | -maxFPS, AI limits, scenario load, mods | You already cut the obvious CPU work and the server still cannot hold its cap at your target player count |
| FPS is stable but warping persists | networkViewDistance, -nds, budgets, location | You have already tightened streaming scope and players in the right region still struggle |
| Memory climbs across long sessions | Navmesh streaming choice, mods, save cadence, restart schedule | Long sessions remain unstable even after trimming persistence-heavy content |
| Join-time hitches hurt live sessions | fastValidation, queueing, mod count | Peak joins still disrupt play after validation and queue behaviour are cleaned up |
| You want more players, heavier Conflict or more mods | Establish a clean baseline first | Your current plan is already near its limit before you add the next layer of load |
If you are at that point, our Arma Reforger hosting comparison is a practical shortlist for rented servers, especially if you want a plan better matched to modded Conflict or larger communities.
If your logs show a real hardware ceiling rather than a bad setting, compare plans built for dedicated game servers and pick one that suits your player count, scenario type and mod load.
Compare the best Arma Reforger hostsArma Reforger server FAQ
What is a good server FPS for Arma Reforger?
A good result is a server that reliably holds its chosen -maxFPS cap during real peak load, not one that briefly posts a high number on an empty map. For most public servers, stability matters more than chasing the highest cap. Watch frame-time max as closely as FPS, because spikes are what players feel.
Does lowering networkViewDistance reduce lag?
Yes, if the lag is caused by replication and streaming rather than the simulation itself. Lowering networkViewDistance reduces how many distant replicated entities the server must consider and send, which saves bandwidth and replication work. The trade-off is more obvious pop-in if you go too low.
How many AI can an Arma Reforger server handle?
There is no fixed number that fits every server. The real limit depends on CPU performance, the scenario, what the AI are doing, how many players are online, and what mods add on top. Find your own limit by watching -logStats: if FPS starts falling and frame-time max rises as AI count grows, set aiLimit below that trouble point and compare again.
Why do vehicles warp on my Arma Reforger server?
If server FPS is low, vehicle warping can come from the simulation itself struggling to keep up. If FPS holds at the cap, the more likely cause is replication scope or network quality: too much is being streamed, the budgets are poorly set, or the player is simply too far from the server. Check logs first, then adjust distance and network settings only if the simulation is healthy.
Do mods make an Arma Reforger server lag?
They can, but not all mods hurt in the same way. Some mostly affect join size, while others add scripted systems, AI, persistence or lots of replicated objects that cost CPU, RAM and bandwidth during play. The safest way to prove it is to add or remove one mod at a time and compare -logStats under the same conditions.
More Arma Reforger server help
Set up your server properly, or compare hosts built for heavy Conflict sessions.
Written for Arma Reforger 1.9. Parameter names, ranges and defaults come from Bohemia’s official server config and startup parameter documentation. If your host’s panel names a setting differently, follow the panel.
