Compression Configuration
Gate supports packet compression to reduce bandwidth usage between the proxy and connected clients. Configure compression thresholds and levels to balance bandwidth savings against CPU usage.Overview
Minecraft protocol supports packet compression using zlib. When enabled, packets larger than a threshold are compressed before transmission, reducing network bandwidth at the cost of CPU resources.Important: These settings apply to Gate ↔ Client connections only. Compression between Gate and backend servers is controlled by the backend server’s configuration.
Configuration
Packet compression settings
Compression Threshold
The minimum size (in bytes) a packet must be before Gate compresses it. The vanilla Minecraft server uses 256 by default.
How Threshold Works
- Packets ≥ threshold: Compressed before sending
- Packets < threshold: Sent uncompressed (compression overhead not worth it)
Threshold Values
- Default (256)
- Lower (64-128)
- Higher (512-1024)
- Disabled (-1)
- Always On (0)
- Balanced bandwidth/CPU tradeoff
- Same as vanilla Minecraft
- Good for typical gameplay
- Recommended starting point
Compression Level
The zlib compression level. Goes from -1 to 9 where:
-1= Default (zlib chooses, usually equivalent to 6)0= No compression1= Fastest, least compression6= Balanced (zlib default)9= Slowest, most compression
Level Comparison
| Level | Speed | Compression | CPU Usage | Use Case |
|---|---|---|---|---|
-1 | Default | Default | Medium | Recommended - Let zlib decide |
0 | Instant | None | Minimal | Testing only |
1 | Very Fast | Low | Low | High throughput priority |
3 | Fast | Good | Low-Med | Good balance |
6 | Medium | Good | Medium | Zlib default |
9 | Slow | Best | High | Bandwidth priority |
Choosing Compression Level
Validation Warnings
Gate validates compression settings on startup:Level Validation
Threshold Validation
Configuration Examples
Standard Server (Recommended)
config.yml
High-Performance Server
Optimized for low latency and high throughput:config.yml
Bandwidth-Constrained Server
Optimized for minimal bandwidth usage:config.yml
LAN Server
No compression needed on fast local network:config.yml
Large Network
Balanced settings for large server with many players:config.yml
Performance Considerations
CPU Impact
Compression uses CPU
Compression uses CPU
Every compressed packet requires CPU time:
- Higher level = More CPU per packet
- Lower threshold = More packets compressed
- More players = More total packets
Per-player CPU cost
Per-player CPU cost
Compression happens per-player connection:With many players, even small per-packet overhead adds up.
CPU vs Bandwidth tradeoff
CPU vs Bandwidth tradeoff
- Lower threshold + higher level = Less bandwidth, more CPU
- Higher threshold + lower level = More bandwidth, less CPU
Bandwidth Impact
Compression ratios
Compression ratios
Typical compression ratios for Minecraft packets:
- Chunk data: 3:1 to 5:1 ratio (excellent compression)
- Entity updates: 1.5:1 to 2:1 ratio (moderate compression)
- Small packets: Less than 1.5:1 ratio (poor compression, overhead not worth it)
Throughput Impact
Compression adds latency
Compression adds latency
Compression/decompression takes time:
- Level 1: ~0.1ms per packet
- Level 6: ~0.5ms per packet
- Level 9: ~2ms per packet
Benchmarking
Test different settings to find optimal configuration:Monitor CPU Usage
Monitor Bandwidth
Testing Methodology
Baseline test
Start with default settings and measure:
- CPU usage
- Bandwidth usage
- Player experience (lag)
Best Practices
Start with defaults
Start with defaults
Match your bottleneck
Match your bottleneck
- CPU constrained: Higher threshold (512-1024), lower level (1-3)
- Bandwidth constrained: Lower threshold (64-128), higher level (6-9)
- Balanced: Use defaults
Consider player count
Consider player count
Test under load
Test under load
Always test compression changes during peak hours with real player load. Synthetic tests don’t reflect real-world usage.
Monitor after changes
Monitor after changes
Watch CPU and bandwidth for at least a few hours after changing settings to see the true impact.
Troubleshooting
High CPU usage
High CPU usage
Symptoms: Gate process using excessive CPUSolutions:
- Increase threshold:
threshold: 512orthreshold: 1024 - Lower compression level:
level: 1orlevel: 3 - Check if issue persists with compression disabled:
threshold: -1
High bandwidth usage
High bandwidth usage
Symptoms: Excessive network trafficSolutions:
- Lower threshold:
threshold: 128orthreshold: 64 - Increase compression level:
level: 6orlevel: 9 - Verify backend servers also use compression
Players experiencing lag
Players experiencing lag
Symptoms: High latency, rubber-bandingCheck if compression related:If lag improves, compression was the issue. Otherwise, problem is elsewhere (backend servers, network, etc.).
Configuration not applying
Configuration not applying
Issue: Changed settings but no effectSolutions:
- Restart Gate (config reload may not apply compression settings)
- Check for validation errors in logs
- Verify YAML syntax is correct
Backend Server Compression
Gate’s compression settings only apply to Gate ↔ Client connections. The Gate ↔ Backend compression is controlled by backend server settings.
Backend Configuration
In backend server’sserver.properties:
- LAN backends: Disable compression (
threshold=-1) to save CPU - Remote backends: Keep compression enabled to save bandwidth
- Match Gate settings: Use same threshold for consistency
Related Configuration
Overview
Complete configuration overview
Servers
Configure backend servers and timeouts
Forwarding
Player info forwarding configuration
Performance
Performance tuning and optimization

