LuckPerms

LuckPerms

Mods
41.4k Downloads

TPS drops when changing world

bobhenl opened this issue ยท 2 comments

commented

Description

Hi, I had a big tps drops when changing world, it took almost over 800ms. I thought it was due to Jobs plugin, but there's something that could be improved in LuckPerms, look here Zrips/Jobs#1113 (comment).

Reproduction steps

  1. I was using PlayerWorlds plugin, but maybe isn't neccessary.
  2. Then I've changed world.
  3. Then I saw big tps drops in spark (you cansee here report for Jobs plugin Zrips/Jobs#1113)

Expected behaviour

Any these big tps drops.... Max 300ms like on the second server... but on this one there were 800ms spikes...

Environment details

  • Server type/version: Tuinity (tried Yatopia & Paper too) running version 1.16.5 build 'on of the latest, I've tried all these 3 forks with new versions, for ex. I can mention Yatopia 33, Tuinity 9ac33d1, Paper 551`
  • LuckPerms version: 5.3.0

This I've got marked by you Luck: : https://spark.lucko.me/60I0727oXJ?hl=9949,14865,42,23,37697
https://spark.lucko.me/pMaNs6uQ7v -> first server, yo ucan see there bukkitCreate event with jobs
https://spark.lucko.me/SF2qwhH2AS -> second server -> without jobs
But problem isn't in Jobs, see the attached issue.

Any other relevant details

Btw I was using https://www.spigotmc.org/resources/%E2%AD%90-playerworldspro-%E2%AD%90-the-nether-and-the-end-support-expiration-1-8-1-16-4.72113/

commented

Looking at the code, I see that in the ChildProcessor class, in the overwritten "refresh" method, it iterates over all the child permissions to update the existing ones according to the Spark report. For this, I suspect you have set a lot of permissions on the database? Usually it is the case that a user has a lot of something and it takes a long time for the CPU to load those elements.
https://github.com/lucko/LuckPerms/blob/6b2c4bca58df120c67ba6dd5b163bc261127829c/bukkit/src/main/java/me/lucko/luckperms/bukkit/calculator/ChildProcessor.java#L59-L66
However, taking into account that in most Map implementations, if Map#put and other methods are called more than once from a given conditional loop, the CPU load time will also increase. This is obvious.

commented

Should be improved by the above commit - although I have a feeling your lag problem actually isn't being caused by this (number of samples is quite low, it's hard to tell).

If the problem continues, it may be worth sampling at a higher accuracy - include the --interval 1 flag.