mirror of
https://github.com/YouHaveTrouble/minecraft-optimization.git
synced 2026-05-11 22:06:56 +00:00
rewrote most of the guide
This commit is contained in:
@@ -37,37 +37,126 @@ It's key to remember that the overworld, nether and the end have separate world
|
|||||||
|
|
||||||
## Networking
|
## Networking
|
||||||
|
|
||||||
### Network-compression-threshold
|
### Network-compression-threshold (`server.properties`)
|
||||||
There is an option in `server.properties` file, called `network-compression-threshold`. This allows you to set the cap for the size of a packet before the server attempts to compress it. Setting it higher can save some resources at the cost of bandwidth, and setting it to -1 disables it. If your server is in a network with the proxy or on the same machine (with less than 2 ms ping), disabling this (-1) will be beneficial, as usually internal network speeds can handle the additional uncompressed traffic.
|
This allows you to set the cap for the size of a packet before the server attempts to compress it. Setting it higher can save some resources at the cost of bandwidth, and setting it to -1 disables it. If your server is in a network with the proxy or on the same machine (with less than 2 ms ping), disabling this (-1) will be beneficial, as usually internal network speeds can handle the additional uncompressed traffic.
|
||||||
|
|
||||||
|
### use-alternate-keepalive (`purpur.yml`)
|
||||||
|
you can enable alternate keepalive system, so players with bad connection don't get timed out as often. Has known incompatibility with TCPShield.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Chunks
|
## Chunks
|
||||||
|
|
||||||
### view-distance
|
### view-distance (`spigot.yml`)
|
||||||
View-distance is distance in chunks around the player that server will tick. Essentially the distance from player that things will happen. This includes mobs being active, crops and saplings growing, etc. You should set this value in `spigot.yml`, as it overwrites the one from `server.properties` and can be set per-world. This option you want to purposefully set low, around `3` or `4`, because of the existance of `no-tick-view-distance`.
|
View-distance is distance in chunks around the player that server will tick. Essentially the distance from player that things will happen. This includes mobs being active, crops and saplings growing, etc. You should set this value in `spigot.yml`, as it overwrites the one from `server.properties` and can be set per-world. This option you want to purposefully set low, around `3` or `4`, because of the existance of `no-tick-view-distance`.
|
||||||
|
|
||||||
### no-tick-view-distance
|
### no-tick-view-distance (`paper.yml`)
|
||||||
This option is added in `paper.yml` and allows you to set the maximum distance in chunks that players will see. This enables you to have lower `view-distance` and still let players see further. It's important to know that while the chunks beyond actual `view-distance` won't tick, they will still load from your storage, so don't go overboard. `10` is basically maximum of what you should set this to. As of now chunks are sent to the client regardless of their view distance setting, so going on higher values for this option can cause issues for players with slower connection.
|
This option allows you to set the maximum distance in chunks that players will see. This enables you to have lower `view-distance` and still let players see further. It's important to know that while the chunks beyond actual `view-distance` won't tick, they will still load from your storage, so don't go overboard. `10` is basically maximum of what you should set this to. As of now chunks are sent to the client regardless of their view distance setting, so going on higher values for this option can cause issues for players with slower connection.
|
||||||
|
|
||||||
### chunk-gc
|
### delay-chunk-unloads-by (`paper.yml`)
|
||||||
`spigot.yml` lest you configure how often unused chunks should be unloaded. `peroid-in-ticks` is time in ticks between the unloads. The default value for this is `600`, however going as low as `400` is recommended, so you reduce the amount of ticking chunks.
|
Lets you configure for how long chunks will stay loaded after player leaves. This helps to not constantly load and unload the same chunks when player moves back and forward. Too high values can result in way too many chunks being loaded at once.
|
||||||
|
|
||||||
|
### max-auto-save-chunks-per-tick (`paper.yml`)
|
||||||
|
Lets you slow down incremental world saving by spreading the task over time even more for better average performance. You might want to set this higher than `8` with more than 20-30 players. If incremental save can't finish in time then bukkit will automatically save leftover chunks at once and begin the process again.
|
||||||
|
|
||||||
|
### prevent-moving-into-unloaded-chunks (`paper.yml`)
|
||||||
|
When enabled, prevents players from moving into unloaded chunks and causing sync loads that bog down the main thread causing lag. The probablility of player stumbling into unloaded chunk is higher the lower your view-distance is.
|
||||||
|
|
||||||
|
### entity-per-chunk-save-limit (`paper.yml`)
|
||||||
|
With the help of this entry you can set limits to how many entities of specified type can be saved. You should provide a limit for each projectile at least to avoid issues with massive amounts of projectiles being saved and your server crashing on loading that. There is an list of all projectiles provided below. Please adjust the limit to your liking. Suggested value for all projectiles is around `10`. You can also add other entities by their type names to that list.
|
||||||
|
```
|
||||||
|
entity-per-chunk-save-limit:
|
||||||
|
arrow: -1
|
||||||
|
dragonfireball: -1
|
||||||
|
egg: -1
|
||||||
|
ender_pearl: -1
|
||||||
|
fireball: -1
|
||||||
|
firework: -1
|
||||||
|
largefireball: -1
|
||||||
|
lingeringpotion: -1
|
||||||
|
llamaspit: -1
|
||||||
|
shulkerbullet: -1
|
||||||
|
sizedfireball: -1
|
||||||
|
snowball: -1
|
||||||
|
spectralarrow: -1
|
||||||
|
splashpotion: -1
|
||||||
|
thrownexpbottle: -1
|
||||||
|
trident: -1
|
||||||
|
witherskull: -1
|
||||||
|
```
|
||||||
---
|
---
|
||||||
|
|
||||||
## Mobs
|
## Mobs
|
||||||
|
|
||||||
### per-player-mob-spawns
|
### per-player-mob-spawns (`paper.yml`)
|
||||||
This option decides if mob spawns should account for how many mobs are around target player already. You can bypass a lot of issues regarding mob spawns being inconsistent due to players creating farms that take up entire mobcap. if you change `per-player-mob-spawns` to `true` in `paper.yml`. This will also make the job easier to properly set entity limits, as it makes the math easier.
|
This option decides if mob spawns should account for how many mobs are around target player already. You can bypass a lot of issues regarding mob spawns being inconsistent due to players creating farms that take up entire mobcap. if you change it to `true`. This will also make the job easier to properly set entity limits, as it makes the math easier.
|
||||||
|
|
||||||
### spawn-limits
|
### spawn-limits (`bukkit.yml`)
|
||||||
Located in `bukkit.yml`. When `per-player-mob-spawns` is enabled the math limiting mobs is just `playercount*limit`, where "playercount" is current amount of players on the server. Logically, smaller the numbers are, less mobs you're gonna see. Reducing this is a double-edged sword, as yes, your server has less work to do, but in some gamemodes natural mobs are big part of a gameplay. You can go as low as 20 or less if you adjust `mob-sapwn-range` properly.
|
When `per-player-mob-spawns` is enabled the math limiting mobs is just `playercount*limit`, where "playercount" is current amount of players on the server. Logically, smaller the numbers are, less mobs you're gonna see. Reducing this is a double-edged sword, as yes, your server has less work to do, but in some gamemodes natural mobs are big part of a gameplay. You can go as low as 20 or less if you adjust `mob-spawn-range` properly. If you are using tuinity, you can set mob limits per world in `tuinity.yml`.
|
||||||
|
|
||||||
### mob-spawn-range
|
### mob-spawn-range (`spigot.yml`)
|
||||||
`spigot.yml` offers an option to reduce the range (in chunks) of where mobs will spawn around the player. Depending on your server's gamemode and its playercount you might want to reduce this value along with `bukkit.yml`'s `spawn-limits`.
|
Allows you to reduce the range (in chunks) of where mobs will spawn around the player. Depending on your server's gamemode and its playercount you might want to reduce this value along with `bukkit.yml`'s `spawn-limits`.
|
||||||
|
|
||||||
### entity-tracking-range
|
### ticks-per (`bukkit.yml`)
|
||||||
Option available in `spigot.yml`. This is distance in blocks from which entities will be visible. Reducing those ranges only saves bandwidth, as entities are still ticked above this range. They just won't be sent to players. If set too low this can cause mobs seem to appear out of nowhere near a player.
|
This option sets how often (in ticks) the server attempts to spawn certain living entities. Water/ambient mobs do not need to spawn each tick as they don't usually get killed that quickly. As for monsters: Slightly increasing the time between spawns should not impact spawn rates even in mob farms. In most cases all of the values under this option should be higher than `1`.
|
||||||
|
|
||||||
|
### entity-activation-range (`spigot.yml`)
|
||||||
|
You can set what distance from the player an entity should be for it to tick (do stuff). Reducing those values helps performance, but may result in irresponsive mobs until player gets really close to them.
|
||||||
|
|
||||||
|
### entity-tracking-range (`spigot.yml`)
|
||||||
|
This is distance in blocks from which entities will be visible. Reducing those ranges only saves bandwidth, as entities are still ticked above this range. They just won't be sent to players. If set too low this can cause mobs seem to appear out of nowhere near a player.
|
||||||
|
|
||||||
|
### despawn-ranges (`paper.yml`)
|
||||||
|
Lets you adjust entity despawn ranges (in blocks). Lower those values to clear the mobs that are far away from player faster. You should keep soft range around `30` and adjust hard range to a bit more than your actual view-distance, so mobs don't immediately despawn when player goes just beyond the point of chunk being loaded (this works well because of `delay-chunk-unloads-by` in `paper.yml`).
|
||||||
|
|
||||||
|
### tick-inactive-villagers (`spigot.yml`)
|
||||||
|
This allows you to decide if villagers should be ticked outside of activation range. This will make villagers proceed as normal and ignore activation range. Disabling this will help performance, but might be confusing for players in certain situations.
|
||||||
|
|
||||||
|
### nerf-spawner-mobs (`spigot.yml`)
|
||||||
|
You can make mobs spawned by monster spawner have no AI. Nerfed mobs will do nothing. You can make them jump while in water by changing `spawner-nerfed-mobs-should-jump` to `true` in `paper.yml`.
|
||||||
|
|
||||||
|
### max-entity-collisions (`paper.yml`)
|
||||||
|
Overwrites option with the same name in `spigot.yml`. It lets you decide how many collisions one entity can process at once. Value of `0` will cause inablity to push other entities, including players. Value of `2` should be enough in most cases.
|
||||||
|
|
||||||
|
### dont-send-useless-entity-packets (`purpur.yml`)
|
||||||
|
Enabling this option will save you bandwidth by preventing the server from sending empty position change packets (by default server sends this packet for each entity even if the entity hasn't moved). May cause some issues with plugins that use client-side entities.
|
||||||
|
|
||||||
|
### aggressive-towards-villager-when-lagging (`purpur.yml`)
|
||||||
|
Enabling this will cause zombies to stop targeting villagers if server is below tps treshold set in `lagging-threshold` in `purpur.yml`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Misc
|
||||||
|
|
||||||
|
### merge-radius (`spigot.yml`)
|
||||||
|
This decides the distance between the items and exp orbs to be merged, reducing the amount of items ticking on the ground. Setting this too high will lead to the illusion of items or exp orbs disappearing as they merge together.
|
||||||
|
|
||||||
|
### alt-item-despawn-rate (`paper.yml`)
|
||||||
|
This list lets you set alternative time (in ticks) to despawn certain types of dropped items faster or slower than default. This option can be used instead of item clearing plugins along with `merge-radius` to gain performance.
|
||||||
|
|
||||||
|
### use-faster-eigencraft-redstone (`paper.yml`)
|
||||||
|
When endabled, the redstone system is replaced by a faster, alternative version that reduces redundant block updates reducing the amount of work your server has to do.
|
||||||
|
|
||||||
|
### disable-move-event (`paper.yml`)
|
||||||
|
`InventoryMoveItemEvent` doesn't fire unless there is a plugin actively listening to that event. This means that you only should set this to true if you have such plugin(s) and don't care about them not being able to act on this event. **Do not set to true if you want to use plugins that listen to this event, e.g. protection plugins!**
|
||||||
|
|
||||||
|
### optimize-explosions (`paper.yml`)
|
||||||
|
Setting this to `true` replaces vanilla explosion algorithm to a faster one, at a cost of slight inaccuracy when calculating explosion damage. This is usually not noticeable.
|
||||||
|
|
||||||
|
### enable-treasure-maps (`paper.yml`)
|
||||||
|
Generating treasure maps is extremely expensive and can hang a server if the structure it's trying to locate is outside of your pregenerated world. It's only safe to enable this if you pregenerated your world and set a vanilla world border.
|
||||||
|
|
||||||
|
### treasure-maps-return-already-discovered (`paper.yml`)
|
||||||
|
Default value of this option forces the newly generated maps to look for unexplored structure, which are usually outside of your pregenerated terrain. Setting this to true makes it so maps can lead to the structures that were discovered earlier.
|
||||||
|
|
||||||
|
### disable-treasure-searching (`purpur.yml`)
|
||||||
|
Prevents dolphins from performing structure search similiar to treasure maps
|
||||||
|
|
||||||
|
### teleport-if-outside-border (`purpur.yml`)
|
||||||
|
Allows you to teleport player to the world spawn if they happen to be outside of the world border. Helpful since the vanilla world border is bypassable and the damage it does to the player can be mitigated.
|
||||||
|
|
||||||
|
### entities-can-use-portals (`purpur.yml`)
|
||||||
|
This option can disable portal usage of all entities besides the player. This prevents entities changing worlds loading chunks on main thread.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -92,7 +181,6 @@ Anything that enables or disables plugins on runtime is extremely dangerous. Loa
|
|||||||
### mspt
|
### mspt
|
||||||
Paper offers a `/mspt` command that will tell you how much time server took to calculate recent ticks. If the first and second value you see are lower than 50, then congratulations! Your server is not lagging! If the third value is over 50 then it means there was at least 1 tick that took longer. That's completely normal and happens from time to time, so don't panic.
|
Paper offers a `/mspt` command that will tell you how much time server took to calculate recent ticks. If the first and second value you see are lower than 50, then congratulations! Your server is not lagging! If the third value is over 50 then it means there was at least 1 tick that took longer. That's completely normal and happens from time to time, so don't panic.
|
||||||
|
|
||||||
|
|
||||||
### timings
|
### timings
|
||||||
Great way to see what might be going on when your server is lagging are timings. Timings is a tool that lets you see exactly what tasks are taking the longest. It's the most basic troubleshooting tool and if you ask for help regarding lag you will most likely be asked for your timings.
|
Great way to see what might be going on when your server is lagging are timings. Timings is a tool that lets you see exactly what tasks are taking the longest. It's the most basic troubleshooting tool and if you ask for help regarding lag you will most likely be asked for your timings.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user