Tuning Arma Reforger Server FPS: AI Limits, View Distance and Join Queue

When players say a Reforger server "feels laggy", they are usually describing a low server frame rate — the simulation tick falling behind — not network latency. The distinction matters, because the fixes are completely different and the settings that help are all server-side.

This is the order worth working through them in. It is impact-ordered, and each step is free.

First, know what you are looking at#

Tuning without measurement is guessing. Before changing anything, get a view of:

• Server FPS / frame time over the session, not a single sample.
• Entity count — AI, vehicles, projectiles — on the same timeline.
• Player count on the same timeline.
• Ping and packet loss averaged across players.

The useful signal is the correlation. If frame time spikes track entity count, the fix is AI or view distance. If they track player count with entity count flat, look at network settings and streaming. If ping is bad while frame time is fine, it is not a performance problem at all — it is a routing or client issue.

1. Cap AI#

operating.aiLimit defaults to -1, which means unlimited. On a busy Conflict server this is the single most likely cause of your problem.

{
    "operating": {
        "aiLimit": 80
    }
}

Start around 80 and adjust. Lower if frame time is still poor at peak; higher if the battlefield feels empty and you have headroom to spare.

For PvP-only servers, remove AI entirely:

{
    "operating": {
        "disableAI": true
    }
}

That transforms the resource profile — a Capture & Hold server with AI disabled runs comfortably on a fraction of what the same player count needs in Conflict.

2. Bring view distance back toward default#

Two fields, both under game.gameProperties:

{
    "game": {
        "gameProperties": {
            "serverMaxViewDistance": 1600,
            "networkViewDistance": 1500
        }
    }
}

The valid ranges go much higher than the recommended ceilings, and that gap is where people get into trouble. Pushing serverMaxViewDistance to 10000 multiplies what the server simulates and streams for a visual difference most players will not notice on a 1600-metre-visibility map.

Note the odd constraint on serverMinGrassDistance: valid values are 0 or 50–150. Anything from 1 to 49 is invalid and will be rejected. Leaving it at 0 lets clients decide, which is what you want.

3. Tune the join queue and save interval#

These do not raise frame rate, but they change how the server behaves under pressure.

{
    "operating": {
        "playerSaveTime": 120,
        "slotReservationTimeout": 60,
        "joinQueue": {
            "maxSize": 20
        }
    }
}

• joinQueue.maxSize defaults to 0, meaning no queue — players hitting a full server just fail. Enabling a queue (up to 50, but 20 or below is sensible) is better for a popular server than making people spam the join button, which is itself load.
• playerSaveTime is seconds between player saves, default 120. Lower means less lost progress on a crash and more disk I/O. On a persistent Conflict campaign, lower is usually worth it.
• slotReservationTimeout is how long a reserved slot is held, 5–300 seconds. Leave at 60 unless you have a specific reason.

4. Audit the modlist#

Mods are the variable most likely to be your actual problem and the hardest to reason about. Anything that adds AI behaviour, dense props, or large terrain is a candidate.

The only reliable method is elimination: remove a suspect mod, run a full session, compare. Slow, but conclusive in a way that reading mod descriptions is not.

Keep this manageable by running a test server that tracks latest while production stays locked — see mod collections and version locking. It also means a mod update that hurts performance shows up on the test server rather than mid-session on the one people use.

5. Only then, consider hardware#

If AI is capped, view distance is sane, and the modlist is audited, and frame time is still poor at peak — then it is a hardware question.

The thing to know is that Reforger is bound by single-thread speed and does not effectively use more than about six threads. So "buy a bigger server" has a ceiling, and past mid-size, running two servers gets you more usable capacity than doubling one. Server requirements covers the sizing logic.

Verify it worked#

1. Validate config.json after each change — the config validator catches the syntax errors that cause a silent boot failure.
2. Restart, and run a full session. An empty server tells you nothing.
3. Compare frame time during the busiest period against the same period before the change, not against the session average.
4. Confirm the change did not cost you something you cared about — capped AI means a thinner battlefield, and that is a real trade-off worth checking with your players.
5. Change one thing at a time. Two simultaneous changes give you a result you cannot attribute.

Trusted references#

• Arma Reforger: Server Config — Bohemia Interactive's field reference
• Arma Reforger: Server Hosting
• Arma Reforger: Startup Parameters