Inactive [ADMN/FIX] MaxTPS - get maximum TPS [1.2.3-R0]

Discussion in 'Inactive/Unsupported Plugins' started by ezzzdiy, Mar 1, 2012.

  1. Offline


    Version: 1.2.3 (Release)
    Bukkit: 1.2.3-R0 (MC 1.2.2 API)
    Dev link:
    Download link:

    It's happened - NOW OPENSOURCED:

    Current maintainers dont have the time to support the plugin atm, NEW MAINTAINERS ARE WELCOME!
    It's most likely we'll return back to the development in a few months, but there is no point holding back code people are finding useful (and constantly bugging us about it).

    Ie, we will give up this project to the first guy who ports it to 1.2 & writes new docs (MaxTPS 2 replaces several parts of minecraft, it also does some more drastic things - like sending far chunks off-server directly from .mca files!)
    Max TPS is a plugin to reduce server lags on most of larger (50+ man) Bukkit servers.

    Although best results are observed in combination with, it works unlike most of the unofficial Bukkit forks aiming at performance.

    The performance is maintained by wisely limiting two heavily taxing things in Minecraft:
    • Number of loaded chunks. This is achieved by dynamically adjusting view-distance.
    • Number of entities spawned. Reduced by stacking items, merging experience orbs and limiting mob-spawners.
    Most of the time, about 20% to 30% performance gains are observed without affecting gameplay much, after that you'l have to resort to dirty tricks such as limiting growth rate and hard mob spawn limits or view distance below 5.

    Detailed info about things lagging your server are obtained via /lag command, it looks like this:
    05:14:24 [INFO] There are 5739 entities, 152 players, 1405 spawnermobs
    05:14:24 [INFO] [############________]/Mem u=6106M f=3792M t=9898M
    05:14:24 [INFO] [####################]/Chunks 36722/30000 (122%)
    05:14:24 [INFO] [##################__]/1min TPS 18.02 avg, 19.24 abs
    05:14:24 [INFO] [###################_]/1sec TPS 19.94 avg, 19.87 abs
    05:14:24 [INFO] [##########__________]/VDist 7 = 225 chunks (3 - 15)
    BEWARE! To coexist with NoLagg disable mob spawn limits and item stack merging in NoLagg!

    Number of chunks in the world

    Every player in game is surrounded by loaded chunks, this is so called 'view-distance' in This
    setting affects server performance drastically, first some numbers:

    view-distance=1: 9 chunks
    view-distance=2: 25 chunks
    view-distance=3: 49 chunks
    view-distance=4: 81 chunks
    view-distance=5: 121 chunks
    view-distance=6: 169 chunks
    view-distance=7: 225 chunks
    view-distance=8: 289 chunks
    view-distance=9: 361 chunks
    view-distance=10: 441 chunks
    view-distance=11: 529 chunks
    view-distance=12: 625 chunks
    view-distance=13: 729 chunks
    view-distance=14: 841 chunks
    view-distance=15: 961 chunks
    So for 50 people online, there must be 50*961=48050 chunks loaded at the same time if you're using view-distance of 15 (14450 for view-dist 8 etc). This is of course worst-case scenario, sometimes people are closer together than view distance, thus sharing some chunks.

    Minecraft processes every chunk loaded, every tick, and only utilize single processor core for that. This imposes hard limit, because best of todays modern CPU/bus architectures seem to be capable of handling 30k-40k chunks max, tps goes down the drain quickly after that.

    A way around it is to simply never go that high with chunk count - just define maximum number of chunks your server is capable of handling and adjust view distance according to that. So lets assume your server is capable of handling of 15k chunks.

    max-dist: 15
    min-dist: 3
    chunk-limit: 15000
    up-interval: 30
    down-interval: 300
    tps-threshold: 18.5
    routine check, 50, 60, 100 and 200 people online:
    • 15000/50 -> 300 chunks per head, switch to view distance 8
    • 15000/60 -> 250 chunks per head, switch to view distance 7
    • 15000/100 -> 150 chunks per head, switch to view distance 5
    • 15000/200 -> 75 chunks per head, switch to view distance 3
    Checks if view-dist can be adjusted are done in definable interval, increase every 30 seconds, decrease every 5 minutes.

    Try to have up and down intervals as far apart as possible, to prevent oscillations. This is because truly hard limits on chunk count cannot be really imposed, some plugins like them always loaded, some other plugin might be unloading some by force .. we're just playing guessing game, however it works reasonably most of the time.

    NEW! Because chunk counts are usually meaningless until significant amount of people are online on the server, view-dist increases are applied ONLY if current TPS is above tps-threshold, likewise decreased when current TPS is below tps-threshold. The aim for defined chunk count still applies, though.

    Figuring out the limits of your server
    1. Install this plugin and check /lag routinely.
    2. Try to find the point when TPS starts going down below your taste and try /maxchunks 14000 followed by /viewdist command without arguments to enforce the change immediately.
    3. Keep repeating 2. while decreasing the number until TPS is back to where you want it.
    Use /mindist, /maxdist and /viewdist with argument only if you truly understand how it works and the implications!

    Limiting number of entities in the world
    item-stacking-radius: 3.5
    mobs-per-spawner: 30
    spawner-check-interval: 30
    ticks-per-monster: 1
    ticks-per-animal: 400
    At this moment, item stacking (including drops) and experience orb merging is used. Another source of lag are XP traps built by players around mob spawners. Every time a spawner creates a monster, it is added to a list of mobs spawned in that chunk. If the mob count exceeds the limit per chunk, no further monsters are spawned by mob spawners in there. "Natural" mob spawn is not affected by this. Mobs remember which chunk they were born in, and the limit will be replenished whenever they despawn/die.

    The check if spawner can be re-enabled is performed every spawner-check-interval. This is because bukkit provides NO MEANS of notification when monster despawns, so we have to count em all once in a while.

    NEW: It is now possible to modify number of ticks after which server tries to spawn monster or animal. Increasing ticks-per-monster to 10 or more can reduce server lags under some circumstances (note that this may affect gameplay because mobs spawn at lower pace). Note that these settings can be found in bukkit.yml, but you need server reloads to change them, this plugins to fine-tune things on-the-fly.

    • Orebfuscator seems to work fine
    • ChunkManager seems to work fine, but set /maxdist 10 to prevent unnecessary overhead (CM ignores view-distance larger than 10)
    • NoLagg 1.70 and higher appears to work correctly - but disable item stack forming and and spawn limits (MaxTPS implements its own, supposedly better).
    • This plugin is written in Groovy language, it depends on its runtime - It's included in the .zip, just so that you're not surprised.
    This is planned for 1.2 release of bukkit:
    • completely custom, smart random monster spawning can reduce mob count to roughly 1/3
    • try to move Packet51MapChunk completely out of main thread, thus making chunk loads asynchronous
    Game commands
    • /lag - shows neatly formatted view of critical server resources (tps, memory usage, view distance, mob counts...)
    • /tps - alias for lag
    • /viewdist - force immediate view distance change
    • /maxdist - set maximum view distance for auto-adjust
    • /mindist - set minimum view distance for auto-adjust
    • /upinterval - interval to try to increase viewdist by 1 (up to maxdist)
    • /downinterval - ditto, but for decrements
    • /chunklimit - number of chunks your server is capable of handling. 5-10k small VPS, 15-25k dedicated, 25-40k big iron
    • /mtreload - reload from config file
    • /stacking - set stacking radius (0 to disable)
    • /spawnerlimit - limit number of mobs per spawner chunk
    • /tpanimal - ticks per animal spawns (400 default = spawn animal every 20 seconds)
    • /tpmonster - ticks per hostile monster spawns (1 default = spawn 20 mobs every second)
    • /threshold - Set TPS threshold for MaxTPS to start affecting view distance. Increases viewdist (up to chunklimit) when current tps is above this number, decreases when current TPS is below this threshold
    Permission nodes
    All permissions are in the format of tps.commandname, for example tps.lag should be given to everyone, the rest only to administrators.
    darklust likes this.
  2. Offline


    Hmmm... shouldn't this be: 50*961=48050

    So, if I have a 20 max player server, I should set chunk-limit to 19220 (20*961)?
  3. Offline


    Ah, yes was counting with 8 viewdist, thanks for spotting :) 19220 if you want 15 view-dist, if you're fine with 10 (default), use 8820 and keep decreasing till you get 20 tps with view-distance auto-adjustments according to player count (it's ok to keep max-dist at 15, unless you're restricted by bandwith)
  4. Offline


    plz do clear items like /nolagg clearall

    its great too limit chanks by groups, admin = 8, default = 3

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 24, 2016
  5. Offline


    You mean, like, some user with permission would keep his viewdistance set, while others get downgraded when chunk limit is reached?
  6. Offline


    yes, or just hard limit by groups without chunk limit is reached
  7. Offline


    Updated to Minecraft 1.2 (CB dev builds). Use at your own risk.
  8. Offline


    Looks epic!
    I use NoLagg, and it doesn't seem to do that much so I am going to use this instead.
    In my opinion, this looks way better for reducing lag.
    ezzzdiy likes this.
  9. Offline


    Note that NoLagg compatibility issues are invastigated - because both plugins work in completely different way, i'll try to implement compatibility with NoLagg - there is no stopping using both, except my lazyness :)
  10. ezzzdiy well actually, if you can manage it better, please do!

    I decided to split NoLagg up in separate performance enhancing plugins:
    chunk sending:
    - configuration compression thread count
    - less memory pollution (reusing raw data buffer for new packets)
    - new sending algorithm
    - configuration sending interval and rate

    - heavily fighting tick rate loss caused by tnt detonation

    - performance logging, showing and tick rate examinator

    item stacker:
    - plugin focused on stacking items and xporbs (if you can do it better, feel free to take it over)

    item buffering:
    - plugin focused on buffering the amount of spawned items in a chunk

    lighting fixing:
    - fixing the failing lighting in chunks (getting rid of dark shadows) and re-sending the chunks

    Most other features (spawn limiter, chunk unload delay, saving interval changer) can be found in many other plugins too, so I feel that having that as well is useless. Plus, the spawn limiter causes more lag than it fixes.

    Since I don't have as much time supporting NoLagg as I could do previously, any features you could implement (better)?

    Also, I strongly suggest splitting up the features you can. Otherwise one faulty component can cause the entire plugin to fail, as happened quite a lot of times in the past.
  11. Offline


    These are the hallmarks of NoLagg, in fact, i believe the stacker is the only one i can do better (at cost of digging deep into net.minecraft, though - being careful with drops during explosions, dont scan all entities to find the ones nearby, just the chunk slice etc).

    Custom chunk sending is sensitive issue overall - there is imo no reason to meddle too much into it (unless youre changing crucial things, such as viewdist), becase bukkit already uses offloading thread for compression and the whole circle vs. cube shows little to no performance increase, it only saves bandwith.

    Indeed, spawn limiting is hard to do right - killing entities makes things only worse. Limiting things which bukkit does not (such as mobspawners) seems to be the only way.

    I'd rather coexist. My plugin focuses at more drastic changes affecting gameplay and i'm trying to keep it minimal already. NoLagg seems to do things much more nicer (at the expense of plugin complexity), mostly focusing to not affect (custom chunk sending may even improve) gameplay.

    Note that MaxTPS is roughly 300 lines of groovy code, compared to several thousands of NoLagg's - bugs are still easy to find.

    However, I will keep your advice in mind when adding some complex features, sir!
  12. ezzzdiy Well, actually, chunk sending is a mandatory fix. Why:
    New chunks, for sending, are put BELOW the sending stack. This means that the chunks previously added are sent before the newly added chunks. This causes the client to quickly lose chunks. Other than that, it uses ungrounded reasons to send chunks. It looks at the amount of packets, instead of the total size of the to send packets. This means that, if a lot of other packets are sent (movement from mobs), no chunks are sent at all. NoLagg fixes this by using the actual scheduled buffer size and by sending chunks each tick using a predefined rate.

    It doesn't end there. It also uses a new alghortihm to make sure the client never ends up without chunks. Even when flying at 200 blocks/second you won't lose chunks. This is a mandatory requirement if you ever want to travel at hyperspeed in trains in TrainCarts :)

    And yes, spawn limiting is a pain. I wanted to actually inject a custom entity spawn function, but I found that I had to completely replace the world...something I'd rather not do as it is cross-referenced everywhere. There are some first-chance listening abilities for worlds (data watchers, IWorldAccess), but I still have to remove the entity then, which comes at an expense.

    Another alternative is to enable and disable animal/monster spawning at set interval. But, world manager that disable and enable it, will fail to work with this.

    Now removing buffered items from Nolagg and placing it in a separate plugin. Hopefully I'll get rid of the meta data too :)
  13. Offline


    Actually, it seems everything gets nicely along in 1.2 with latest NoLagg once i stopped fiddling with the chunk queue under its hands :). Never really figured out where exactly the clash happend (player getting missing chunks), however it doesnt happen anymore.

    Revised my statements in OP.
  14. ezzzdiy NoLaggChunks uses a linkedlist-extending class called 'ChunkSendQueue'. In there it handles all functions which add/remove chunks from the queue for sending. The entityplayer chunkSendQueue is replaced with this one. It fakes being always empty (get always returning null, size 0 and isEmpty true) to prevent Spout from trying to sort the contents all the time. (it was using the annoying spiral-based sorting)

    You can still add and remove chunks from it with ease. When removing it even cancels the further loading of the chunk and/or compression of the chunk packet.

    So, unless you try to hack yourself in removing all coordinates, it will not really cause compatibility issues.
  15. Offline


    I don't even need to touch it - everything i do (forcing chunk maps/unmaps) should be going through PlayerManager, as it does now.
  16. Offline


  17. Offline


  18. Offline



    As you sure know, there's a hardcoded min viewdistance in MC (view-distance=3). With your plugin we are able to go to a LOWER than 3 viewdistance or I'm wrong ?



    I own the biggest MC server in business, VIEWDISTANCE has always been a problem, because it use alot of CPU and bandwidth. I've asked Cojito, Afforess and even bergerkiller for the possibility of using a lower than 3 viewdistance. None of them could give me a solution. Now with MaxTPS i'm running with viewdistance=1 and so far no bugs. (will test it a little more btw)

    Here a SS of my servers with 900+:

    Thank you ezzzdiy, you are my new god.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 24, 2016
  19. Offline


    Note that viewdist 1 may cause some odd glitches :/ Btw, I once visited craftlandia to see what you did there with view-dist 5 :)
  20. Offline


    UPDATE: Well, I've just tested it better, it has the same bugs that the Cojito's and Afforess build had :(

    01) With viewdistance=1 sometime players cannot grab itens from the ground (i.e: break a dirt, cannot grab it)
    02) Mobs act strange, doesn't attack (even in hard mode)

    Please take a look on this.
  21. Offline


    Nothing to be done, minimum safe view-dist is 3. 1 breaks everything :(
  22. Offline


    I see.. well, thank you anyway ezzzdiy, it's pretty impressive you did it with only a plugin :)
  23. Offline

    Nathan C

    Is this better than NoLagg?
  24. Offline


  25. Offline


    Is it possible to change VDist for every player ?

    I mean for example if player is undeground or in cave, why does he need Vdist of 10, can't we change for him 3-5 ?
  26. Offline


    It is possible to have different viewdist for every player. However increasing viewdist is very taxing on the server - imagine scenario:

    1. player goes to cave, viewdist goes 15 -> 5
    2. player goes out of cave, viewdist goes 5 -> 15

    The second change (increasing viewdist a lot) hits the server hard - it has to load all the chunks again, just because the player moved. This can be solved by some sort of heuristic (eg. if hes in the cave long enough, its safe to assume he'll stay some longer).

    All in all, view-dist could be configured per worldguard region, guessing where it's really necessary and where not is too hard for us, so server admins should do it instead :)
  27. Offline


    One more question, does this plugin effect how much seeds i get from wheat or how much seeds i get from tall grass ?
  28. Offline


    Very interesting and a great potential for an alternative to NoLagg (which is also great).

    However, I have a concern: Is there experimental data that clearly indicates the benefits of running this plugin? Did anyone actually ran a testing environment where the entire environment is simulated (player number, player behavior, player location, etc), with and without the plugin?

    The reason I ask this is because when NoLagg came, some people found that their servers had less lag, while others said it opposite and that it increased CPU and memory usage. There were no definitive testing done that indicates the improvements of the plugin.
  29. Offline


    The benefits directly correlate with the "make the game look worse, to increase TPS". Ie the view-distance is understood by most server admins that after some critical threshold (say, 50 people online), it plays significant role. MaxTPS provides no optimization in itself, just the ability to scale that factor according to server load (few people = game looks nicer).

    Servers below 50 people online will hardly notice any difference, and the same probably goes for nolagg and it's chunk sending optimization.

    Note that i'm using NoLaggTNT and NoLaggChunks on my server, because these two are indeed important in my opinion. Fiddling with chunk (un)loading is an issue with mixed results in case of NoLagg, simply because it provides simple caching mechanism (which potentially increases memory usage), but it doesn't fix the underlying issue - these bastards are loaded synchronously in the main thread.
  30. Offline


    That's nice. Thanks for clearing up for me.

Share This Page