[BUG] Cyclical churn

[SlimeDog]

>version
[11:41:56] [Server thread/INFO]: This server is running CraftBukkit version git-Spigot-0509002-6b95d59 (MC: 1.16.1) (Implementing API version 1.16.1-R0.1-SNAPSHOT)
[11:41:56] [Server thread/INFO]: You are running the latest version

>version BigDoorsOpener
[11:42:04] [Server thread/INFO]: BigDoorsOpener version 2.2-BETA
[11:42:04] [Server thread/INFO]: Open and close doors automatically on certain conditions
[11:42:04] [Server thread/INFO]: Website: www.spigotmc.org/resources/80805/
[11:42:04] [Server thread/INFO]: Author: Hadde

Problem Since the introduction of V2, BigDoorsOpener creates a small but significant churn every 10 minutes, resulting in TPS drop. No players are connected for this test. No actions are logged by BDO.

Note that checkUpdates: false

Please explain what is it doing, and the purpose.

Config Please include a copy of your config with at least one door object

# dont touch it or at least dont complain when everything burns.
version: 1
checkUpdates: false
refreshRate: 20
language: en_US
timedRefreshRate: 20
enableMetrics: true
jsCacheSize: 400
doors:
- ==: conditionalDoor
  doorUID: 3
  world: world_westeros
  position:
    ==: Vector
    x: 805.5
    y: 68.0
    z: -4577.0
  invertOpen: false
  evaluator: ''
  evaluationType: OR
  stayOpen: 0
  conditionChain:
    ==: conditionChain
    item: null
    permission: null
    location: null
    time:
      ==: timeCondition
      openTick: 23750
      closeTick: 13000
      forceState: false
    weather: null

... and 5 more door objects

[rainbowdashlabs]

The plugin does not contain something which can affect the performance like this.

There are three mechanics which are called.

1. The auto updates which enables a join listener and calls the spigot api once a time on startup. Which is not enabled. So it cant be the reasion.
2. Metrics. These are send every 30 Minutes so there is not obvious way why they should cause 10 minutes spikes.
3. DoorChecker. This scheduler checks every tick one door. This should also not cause periodical tps spikes.

I assume that you tested this on a barebone server with only big doors and BDO enabled right?

Are these spikes nearly periodic in a 10 minutes cycle?

Would it be possible for you to switch to paper for testing purposes and provide some timings or a screenshot of the timings which display these. Or if you dont want to share it can you check if there is something going on with chunk loading? I think in another way it would be possible to track this down, since I can't reproduce it or see a similar behaviour on my test or productive system.

[SlimeDog]

I cannot switch to Paper; it breaks some of my plugins. And unfortunately, Spark (much better timing information) is currently broken on 1.16.1.

What I see: If I disable BDO, the TPS evidence of the churn disappears, and I get flat TPS 20.0.

How often does BDO check for updates?

[rainbowdashlabs]

BDO only checks for updates if its enabled in the config. Than it will be called one time on startup. It will not check for updates while running.

The door updates are spread over 20 ticks with your settings. Which means that each foot will receive at least one update every 20 ticks. This point has still place for improvement, but it should not cause spikes because its more a linear behaviour. If this would cause problems, you would have constantly low tps.

If you have only 6 doors like you stated above every door will have received an update after 6 ticks. I really dont know what the cause can be. I suspect a garbe collection process of the server. Also Big Doors loads a chunk when the door is in a unloaded chunk if I remember correct. But I dont think that the server unloads these chunks every 10 minutes. That seems a long time to keep a chunk loaded.

[SlimeDog]

Thanks for the information. Likewise, I have no idea what's going on; I'm reporting what I see. As you say, 10 minutes seems a long interval for GC.

I can live with this -- as I noted above, the TPS decrement is small, but I like to investigate all such issues, so they don't accumulate into larger issues.

Should I increase the refreshRate or timedRefreshRate? As you can see, these doors are on timers for open/close; I don't know that I need them checked every second. How are the two settings different, and what would be the expected impact?

[SlimeDog]

Another thought: Could BDO cause BigDoors to do something every 10 minutes?

[rainbowdashlabs]

I suggest to wait for the 2.2.1. The goal of this version is exactly what you want.

The current issue is that raising the refresh rate would only have an effect if you have more than 20 doors.

The next version will ensure that a) a door is really only refresh once every 20 ticks. b) uses caching to not always recalculate the condition even when its not needed (E.g. We dont need to calculate the time 20 times a second. Instead it will only calculate the door state of timed door every 5 seconds which will be totally enough)

These two changes showed a 40% to 60% decrease in calculation duration with 20 doors. So maybe this can solve your issue.

I also looked a bit into the Big Doors code which pim gave me access too thankfully and will investigate further if there is an issue and will talk to pim if neccessary.

The 10 minutes interval is still strange. I think as well that it must be something between BigDoors and BDO. Maybe we will get more insights when the timings are working again on spigot. I will as well setup a spigot server on 1.16 and look if I get the same issue there.

[SlimeDog]

Sounds great! Thanks.

[SlimeDog]

The issue has been resolved.

I have six doors that are toggled at dawn and dusk, so 10-minute interval IRL. It's surprising (to me) that six doors would cause a noticeable TPS drop. But at least we have an explanation. Apologies for not realizing the cause sooner.

[rainbowdashlabs]

Oh well yeah. That seems legit.

I may integrate a Queue of doors which should be toggled in the next update. In this way you could still toggle them on the same time but they will be executed slighty delayed each. This will also spread the needed cpu time.

Also since you can copy door conditions this will be a common issue probably many user will have with more doors. So I think this would be a good improvement.

[SlimeDog]

With all six doors toggling simultaneously, there are 514 blocks to move. That means 514 blocks to convert to entities, and 514 entities to spawn, transport, and despawn. So the impact is understandable.

Door pair 3/4: blocks=138 range=2 type=portcullis Door pair 5/6: blocks=212 range=10 type=portcullis Door pair 8/9: blocks=164 range=3 type=door

What is the impact of jsCacheSize? Currently set to 400 (default).

I don't know that complicating the plugin with queuing/sequencing is necessary. I edited the timers to sequence the door pairs myself, at 200-400 tick intervals, so at most 212 entities to move at once. That spread the load over the course of an IRL minute, but did not reduce the TPS drop, which at its most granular is a one-minute average.

[rainbowdashlabs]

The js cache is for caching results of the placeholder condition and the custom evaluator. As js is quite expensive i cache the most used operations for a certain duration to not compute them again if i need them often.

It will be empty if you dont use placeholder conditions or a custom evaluator and wont have any impact.

I think this queuing is needed. Otherwise other people would have the same issue like you, but maybe without understanding what the cause is. And there is the copy condition and clone door command wich would be useless if you have this behaviour because you should never copy a door with a time condition.

[SlimeDog]

I set the relevant chunks to forceload, and now the TPS drop is negligible. So that is the way to go. Suggestion: mention that as an optional setup step.