Optimizing a Garry's Mod Server: Cut Lag for Good

1 Understand the bottleneck first

Garry's Mod runs on the Source engine, and the server's main loop — networking, physics and all Lua — runs on a single CPU thread. That one fact explains most GMod performance:

• Adding more CPU cores barely helps the tick. Clock speed (single-thread performance) is what matters.
• Every prop's physics and every addon's per-tick Lua compete for that one thread.
• When the thread can't finish a tick in time, you get the classic "rubber-banding," delayed tool guns and chat lag.

So optimization isn't about one magic convar — it's about reducing what runs on that thread and giving it a fast core to run on.

2 Measure before you change anything

Guessing wastes hours. Source ships with a profiler called VProf — run it in the server console while the server is busy:

vprof_on
// ...let it run for 20-30 seconds under load...
vprof_off
vprof_generate_report

The report shows where frame time goes — physics, server Lua (look for GMOD / LuaHook lines), networking. If a single hook or system dominates, you've found your culprit. For Lua specifically, a profiler addon (search the Workshop for a "Lua profiler" / "lag detector") will attribute time to individual addons and hooks.

Also keep an eye on the basics in console: status (players + ping) and your host's CPU graph. If CPU is pinned at 100% on one core with only a handful of players, that's a Lua/physics problem, not a "needs more RAM" problem.

3 Cut prop & entity spam — the #1 cause

Physics props are expensive, and players will spawn hundreds if you let them. Tighten the sandbox limits and keep the map clean:

• Lower your sbox_max* limits to sane numbers for your player count. Our Sandbox Limits Calculator generates a sensible block and shows the server-wide prop ceiling it implies.
• Run prop protection — Falco's Prop Protection (FPP), bundled with DarkRP, stops one player melting the server with prop spam and lets you clean up orphaned props.
• Clean up regularly. gmod_admin_cleanup wipes spawned props; many admin mods add auto-cleanup of disconnected players' props. Clear decals with r_cleardecals pushed to clients.
• Watch contraptions. Wiremod and physics contraptions (constrained prop chains) are tick-killers — cap wheels/thrusters/constraints, not just props.

4 Bisect your addons

On a laggy server, one or two addons are usually doing 80% of the damage — often an abandoned Workshop addon with a sloppy Think or HUDPaint hook that runs heavy work every frame. The fastest way to find it is a binary search:

1. Note your idle tick performance with everyone off the server.
2. Disable half your addons. Measure again under the same conditions.
3. Whichever half made the bigger difference, keep digging into that half. Halve again, measure again.
4. Within a few rounds you've isolated the offender.

Then decide: update it, replace it with a maintained alternative, or cut it. Be especially suspicious of: all-in-one "server packs," anything that hasn't been updated in years, multiple addons doing the same job, and anything advertising "100+ features."

5 Tune tickrate & network rates

GMod runs at a fixed tickrate set on the launch line with -tickrate. Higher tickrate = smoother movement and hit registration, but more CPU per second. Most servers sit somewhere between 22 and 66 — pushing it higher than your CPU can sustain makes things worse, not better.

// example launch line fragment
srcds -game garrysmod -tickrate 33 +maxplayers 64 +gamemode darkrp +map rp_downtown_v4c_v2

Set sane network rates in server.cfg so clients can actually keep up:

sv_minrate 80000
sv_maxrate 0          // 0 = unlimited per-client cap
net_maxfilesize 64    // allow larger Lua/content transfers
sv_allowdownload 0    // serve content via FastDL instead (faster)

Serving content over FastDL instead of the slow in-game route is one of the biggest "join time" wins, and it takes load off the game server.

6 Clean up your own Lua

If you write or edit addons, a few habits prevent most self-inflicted lag:

• Don't do heavy work in Think / HUDPaint. They run every frame. Move logic to timer.Create at a sane interval, and cache results.
• Avoid ents.FindInSphere / player.GetAll() loops every tick. Cache the list and refresh it on a timer.
• Network with the net library, not the deprecated umsg, and only send what changed — don't broadcast state every tick.
• Localize globals in hot paths (local FindInSphere = ents.FindInSphere) and avoid creating tables/functions inside frame hooks.

Starting a new gamemode? Our Gamemode Skeleton Generator scaffolds the correct server/client/shared split so you're not piling logic into the wrong realm.

7 Give it the right hardware

After you've trimmed props, addons and Lua, the remaining ceiling is hardware — and for GMod that means one thing above all:

• High single-thread clock speed. A fast modern core will hold tick where a many-core "server" CPU chokes. See game server hardware explained.
• Enough RAM for your addon list. Big DarkRP installs with hundreds of addons want headroom — but RAM won't fix a tick problem; clock will.
• NVMe storage for fast map changes and Lua/content loading.
• DDoS protection — a downed server is the ultimate "lag."

✓ Quick checklist

1. Measure with vprof_generate_report under load — don't guess.
2. Cut props: lower sbox_max*, run FPP, clean up regularly.
3. Bisect addons to find the heavy one; update, replace or remove it.
4. Tune -tickrate to what your CPU sustains; set rates; use FastDL.
5. Fix your Lua: no heavy work in Think/HUDPaint; cache; use timers.
6. Hardware: fast single-thread CPU > core count, every time.