Minecraft Server Caching: How to Use Caching Plugins and Settings to Drastically Reduce Server Load
# Minecraft Server Caching: How to Drastically Reduce Server Load
One of the most underrated techniques in Minecraft server optimization is caching — storing the results of expensive calculations so they don't have to be repeated every tick. While most admins focus on view distance, entity counts, and JVM flags, smart caching can cut your server's CPU usage significantly without changing a single gameplay mechanic.
In this guide, you'll learn exactly what caching means in the context of a Minecraft server, which settings already use it, and how to layer additional tools on top for maximum performance.
---
What Is Caching in a Minecraft Server Context?
Every tick (50ms at 20 TPS), your server performs thousands of small calculations: checking nearby entities, evaluating pathfinding, querying permissions, looking up economy balances, and more. Many of these calculations return the same result repeatedly — for example, a player's rank doesn't change every second, yet some permission plugins query it dozens of times per tick.
Caching stores the result of a computation temporarily so the server can reuse it without recalculating. Done right, it's one of the highest ROI optimizations you can make.
---
Built-in Caching in Paper and Purpur
Modern forks like Paper and Purpur already implement several caching layers you should be aware of:
Chunk Caching
Paper maintains an in-memory chunk cache to avoid loading chunks from disk repeatedly. You can influence this indirectly via server.properties:
# server.properties
view-distance=8
simulation-distance=4
Keeping these values moderate reduces the number of chunks Paper must cache simultaneously, freeing memory for other operations.
Entity Lookup Caching
In paper-world.yml, several settings control how often entity lookups are refreshed rather than recalculated live:
# paper-world.yml
entities:
spawning:
count-all-mobs-for-spawning: false
This prevents the server from iterating every loaded entity on every spawn attempt — a form of lookup caching.
alt-item-despawn-rate (Paper)
Instead of checking every item entity every tick, Paper's alternate despawn rate lets you assign different timers to cheap vs. expensive item types:
# paper-world.yml
entities:
spawning:
alt-item-despawn-rate:
enabled: true
items:
COBBLESTONE: 300
NETHERRACK: 300
DIRT: 300
Fewer item entities means fewer iterations — effectively reducing the set of objects the server needs to cache and track.
---
Caching Permissions with LuckPerms
Permission checks are one of the most frequent background operations on a busy server. LuckPerms — the gold standard for permissions — includes a built-in caching system, but it needs to be configured properly.
In LuckPerms/config.yml:
# Use a fast storage backend for cache warmup
storage-method: h2 # or mysql for large networks
# Enable watch mode only if you need live config reloads
watch-files: false
LuckPerms caches permission lookups in memory per player after the first evaluation. Avoid plugins that call player.hasPermission() in hot loops — this bypasses the cache and triggers unnecessary recalculations.
> Tip: Use LuckPerms' /lp verbose command to identify which plugins are making excessive permission checks.
---
Economy Caching with Vault and EssentialsX
Every time a plugin checks a player's balance via the Vault API, it hits your economy backend. On servers with active shops or auto-sell plugins, this can mean hundreds of balance lookups per second.
EssentialsX stores economy data in flat YAML files by default. For servers with 50+ concurrent players, switch to a database backend and enable async operations:
# EssentialsX config.yml
use-storage-file: false
storage:
backend: SQLite # or MySQL for larger networks
Some shop plugins like ShopGUI+ and DeluxeMenus include their own balance-caching layer. Enable it explicitly if available — check each plugin's config.yml for a cache-balance or update-interval option.
---
Placeholder Caching with PlaceholderAPI
PlaceholderAPI is one of the most common performance culprits on busy servers. Every placeholder that's evaluated live (e.g., in a scoreboard refreshing every second) can trigger dozens of database or API calls per player.
Use the PlaceholderAPI Cloud Expansions that include caching, or install TAB as your scoreboard/tablist plugin — it has an aggressive built-in placeholder cache:
# TAB config.yml
placeholders:
refresh-intervals:
default: 500 # ms — don't go below 200ms
"%vault_rank%": 5000 # Rank doesn't change often — cache for 5 seconds
"%player_ping%": 200 # Ping changes fast — short cache
Tuning per-placeholder refresh intervals is one of the fastest wins for servers running complex scoreboards or holographic displays.
---
World and Biome Data Caching
When your server generates or accesses chunks, it reads biome data for mob spawning calculations, weather effects, and more. In Paper, you can enable biome caching to reduce repeated biome lookups:
# spigot.yml
world-settings:
default:
mob-spawn-range: 6
nerf-spawner-mobs: false
Purpur goes further with additional caching for block data and tick scheduling:
# purpur.yml
world-settings:
default:
blocks:
disable-mushroom-updates: false
disable-chorus-plant-updates: false
Disabling updates for rarely-changing block types reduces the number of objects requiring cached state tracking.
---
Plugin-Level Caching: Best Practices
If you develop or heavily configure plugins, apply these caching patterns:
- Cache per-player data at login — load stats, permissions, and preferences into memory when a player joins, not on demand.
- Use
BukkitRunnablewith intervals instead of responding to every event. For example, update a leaderboard every 30 seconds rather than on every kill event. - Avoid synchronous database calls in event handlers. Always run queries async and cache the result.
- Set explicit TTLs (time-to-live) on cached values. Stale data is better than repeated lookups in most cases.
---
Monitoring Your Cache Effectiveness
Caching only helps if it's actually working. Use Spark (/spark profiler) to identify which methods are being called most frequently — if you see permission checks, placeholder evaluations, or database queries dominating the flame graph, your caching layer isn't doing its job.
For a broader view of your server's health over time — including TPS trends, memory usage, and entity counts — [PulseNode](https://pulsenode.tech) gives you real-time and historical performance data in one dashboard, making it easy to spot when a caching regression causes lag spikes.
---
Summary: Quick Caching Checklist
- ✅ Set moderate
view-distanceandsimulation-distanceinserver.properties - ✅ Enable
alt-item-despawn-rateinpaper-world.yml - ✅ Use LuckPerms with
/lp verboseto find hot permission checks - ✅ Switch EssentialsX economy to SQLite/MySQL for high player counts
- ✅ Set per-placeholder refresh intervals in TAB or similar plugins
- ✅ Cache per-player data at login in custom plugins
- ✅ Profile with Spark to verify caching is actually reducing overhead
Caching isn't a silver bullet, but combined with the other optimizations in your toolkit, it can mean the difference between a server that struggles at 50 players and one that handles 150 with ease.
---
*Want to know whether your caching improvements are actually working? [PulseNode](https://pulsenode.tech) tracks your TPS, memory, and CPU usage in real time so you can measure the impact of every change you make.*