Plugins that spam use repeating task timers are filling up the CustomTimingHandler list, which can degrade performance over time
Considering Essentials does this, and many servers use Essentials... def need to stop this.
This greatly extends the timings improvements I've done in recent commits, and brings timings to fully cover the entire tick.
The timings system also now tracks when specific timings causes the server to lose TPS.
The timings are also able to be turned on "on demand", meaning you do not need to restart the server to enable them.
This commit also overhauls the Entity Activation Range feature, fixing bugs, adding more immunities, and improving the performance of it.
It also fixes a regression with a recent Spigot commit that broke the entire Entity Activation Range feature.
This commit had to move the Tick Loop patch before timings because there was a change done there to time the entire tick, so lots of renames.
These 2 commits had to be bundled together to simplify applying them and reduce redundant conflict resolution.
The previous version missed the entire point of the change and made it only skip collision on NON living entities... which is not often at all.
It was meant to only Skip Living->Living, or else we won't get any gain...
== Plugin incompatibilities
As a side effect of this change, plugins which rely on very specific implementation level details within Minecraft are broken. At this point in time, TagAPI and ProtocolLib are affected. If you are a user of ProtocolLib you are advised to update to the latest build, where full support is enabled. If you are a user of TagAPI, support has not yet been added, so you will need to install the updated ProtocolLib so that TagAPI may use its functions.
== Stability
The code within this commit has been very lightly tested in production (300 players for approximately 24 hours), however it is not guaranteed to be free from all bugs. If you experence weird connection behaviour, reporting the bug and steps to reproduce are advised. You are also free to downgrade to the latest recommend build, which is guaranteed to be stable.
== Summary
This commit provides a reduction in threads, which gives the CPU / operating system more time to allocate to the main server threads, as well as various other side benefits such as chat thread pooling and a slight reduction in latency.
This commit is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported license.
IIRC, the main item I was driving towards was a consequence of persistent passive mobs - specifically, the fact that allowing a population limit of N (independent of view distance, which is what vanilla does) when your view distance limits actual loaded chunks to a much smaller area than default (say a view of 4, which would be 9 x 9 chunks loaded per player - and spawnable - versus default, which is 8 radius spawn, or 17 x 17 chunks) tends to result in more mobs per chunk. For persistent mobs, this is bad - since they count for server load and for population just by being loaded, versus being despawned beyond 128 blocks (8 chunk radius - unconditional of view distance, as well) - so they can cause the population limit to be reached more easily, cutting off spawning nearer to players. The goal was to make it so that the mobs-per-loaded-chunk was about the same for all view distances, versus having low view distances cause higher mob concentrations.
Now, all of this assumes that loaded chunks beyond those around players are modest (since they could contain passive mobs that would count towards the limits) - which they should be, except that recent CBs leak chunks like mad, from what I can see (chunk-gc has become more required than optional), and I think there may be some issues with even hostile mobs "lurking" around - possibly even after their chunks are unloaded. Anything that causes more mobs to be in places players don't see them is going to drive population limit issues, and resulting low spawn behaviors. The trick for us, trying to make big servers as practical as possible, is to shift the math the other way - given low view distances, how to best make sure that folks get reasonable spawn behavior while minimizing the time/resources spent on the server on mobs that don't help that. Realistically, I think we need to analyse the mob demographics better - especially as it relates to lower view distances (our changes have no net impact on view distances above 7) - particularly to understand how the proportion of "useful" mobs is working out (ones close enough to players to be considered contributing to game play). One thought is to manage the population limit based on mobs that are 'tickable' - if they aren't close enough to be ticking, they aren't interesting. This is likely a big issue for view distance 5 folks, since mobs cannot spawn closer than 24 (approx 1 chunk radius, given that middle chunk is 0), and don't tick when any of the chunks within a 2 chunk radius aren't loaded) - so, effectively, they "live" within a zone of 7 x 7 with the middle 3 x 3 removed (so, about 40 chunks) out of a total load zone of 11 x 11 (121) - so about 2/3 of the area containing mobs has idle mobs. Normal view distance would result in mobs ticking as far out as they can spawn (radius 8 versus a load radius of 11), so 100% of the mobs that spawn are ticking when they spawn, and all hostile mobs that are loaded are ticking (since they always despawn beyond 128 blocks / 8 chunks from a player). One interesting thought would be to limit the chunks we spawn mobs in to those where they would be ticking initially (that is, view-distance minus 2 or 3).
md_5
Aikar
SuPaH sPii
Keir Nellyer
shakytom
Mike Primm
Agaricus
md_5