Menu
 

HumanitZ Server Performance Optimization Guide

HumanitZ Server Performance Optimization Guide

HumanitZ's dedicated server is an Unreal Engine simulation — it runs physics, zombie AI, vehicle tracking, loot spawning, and network replication simultaneously for every active player. Even well-specced hardware can show performance degradation if the server config isn't tuned to match your player count and playstyle. This guide covers every performance lever available to a server operator.

📊 Primary Bottlenecks

In order of typical impact: CPU (zombie AI calculations), RAM (world object tracking), Storage I/O (autosave operations), Network (tick rate delivery). Each has specific remedies.

🔍 Monitor First

Identify your actual bottleneck before changing settings. Tuning CPU-related settings when the real problem is disk I/O wastes time and can mask the real issue.

Monitoring Server Resources

# Watch CPU and RAM in real time (Linux):
htop

# Filter to just the HumanitZ process:
watch -n 5 "ps aux | grep TSSServer | awk '{printf \"CPU: %s%%  RAM: %sMB\n\", \$3, \$6/1024}'"

# Disk I/O during autosave (install iotop if needed):
sudo iotop -o -P | grep TSS

CPU Optimisation: Zombie AI Settings

Zombie pathfinding is the #1 CPU consumer on busy servers. These settings in GameServerSettings.ini directly impact CPU load:

[ZombieSettings]
# Hard cap on AI-tracked zombies (lower = less CPU)
MaxActiveZombies=150          ; Default is often 300 — halving this ~halves zombie CPU cost

# Radius within which zombies are fully simulated
AIActivationRadius=120        ; Metres — keep tight, especially in city map

# Distance at which zombies switch to cheap "dormant" state
AISimplifyRadius=200

# AI pathfinding recalculation interval (seconds — higher = cheaper)
PathfindTickRate=0.75         ; Default 0.25 — increase for smoother frame pacing

# Zombies per player (scales total population with player count)
ZombiesPerPlayer=8            ; Reduce to 4-6 for large player counts

RAM Optimisation: World Object Limits

[WorldSettings]
# Maximum vehicles tracked simultaneously
MaxWorldVehicles=60           ; Each vehicle = persistent RAM allocation

# Maximum dropped item entities on the ground before oldest are removed
MaxGroundItems=500

# Frequency of world-state garbage collection (seconds)
GCInterval=300                ; Lower = more frequent cleanup, small CPU cost

Storage I/O Optimisation: Autosave

Autosave operations briefly block the simulation tick, causing all players to experience a lag spike. Reducing save frequency is often the single most effective anti-lag change:

[ServerSettings]
# How often the server auto-saves (seconds)
AutoSaveInterval=300          ; Default is often 60 — increase to 300 or 600

# Save immediately when a player disconnects (adds small I/O on each logout)
SaveOnPlayerDisconnect=false  ; Disable on high-traffic servers

Storage hardware: If autosave still causes spikes after reducing frequency, the underlying issue is slow storage. Move the server installation to an NVMe SSD — HDD or even SATA SSD can bottleneck save operations on large, built-up worlds.

Network Tick Rate

[NetworkSettings]
# Server simulation ticks per second delivered to clients
ServerTickRate=30             ; Default 30 — increasing to 60 improves feel but doubles bandwidth

# Max network packets sent per tick per client
MaxPacketsPerTick=64

# Client update rate (how often each client receives world updates)
NetUpdateFrequency=20         ; Higher = smoother for clients, more CPU/bandwidth needed

Player Count vs Hardware Guide

PlayersRecommended CPURAMMaxActiveZombies
1–84 cores @ 3.5 GHz8 GB200
9–166 cores @ 4.0 GHz16 GB150
17–308 cores @ 4.5 GHz32 GB100
31–4012 cores @ 4.5 GHz64 GB80

Common Performance Anti-Patterns

  • Running on an HDD: Autosave I/O is catastrophic on spinning disk — always use SSD/NVMe
  • MaxActiveZombies at default 300 with 30+ players: The AI calculation load compounds multiplicatively beyond ~150 zombies
  • AutoSaveInterval=60: A save every minute freezes the simulation noticeably — move to 300+ seconds minimum
  • Running the server as root: Not a performance issue, but prevents normal memory protection signals that can cause silent crashes under load
  • Sharing the server machine with other games or services: Competing processes steal CPU time during peak load — dedicate hardware to HumanitZ

Scheduled Restart for Memory Reclamation

HumanitZ's server process accumulates memory gradually. A daily restart at low-population time reclaims RAM and resets any fragmentation:

# Linux cron — restart at 05:00 daily:
0 5 * * * systemctl restart humanitz.service

Benchmarking tip: After any config change, let the server run for at least 2 hours under normal player load before judging the impact. Short-term performance can be misleading because the server's save graph and AI state pools are smaller immediately after a restart than during a steady-state session.

Professional Hosting

Get hardware optimised for HumanitZ from the start. Host your HumanitZ server with Supercraft on NVMe-backed, high-clock-speed CPUs tuned for Unreal Engine survival game workloads.

Top