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
| Players | Recommended CPU | RAM | MaxActiveZombies |
|---|---|---|---|
| 1–8 | 4 cores @ 3.5 GHz | 8 GB | 200 |
| 9–16 | 6 cores @ 4.0 GHz | 16 GB | 150 |
| 17–30 | 8 cores @ 4.5 GHz | 32 GB | 100 |
| 31–40 | 12 cores @ 4.5 GHz | 64 GB | 80 |
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.