discordsrv.objects.Lag monitoring causing lag spikes / lag.
mibby opened this issue ยท 8 comments
Paper dev 175 (Spigot 1.14.4)
DiscordSRV compiled as of this commit/branch 6b3e091
Any way to optimize the check or disable it entirely if not needed? It seems to be causing lag spikes for me despite TPS being stable at 20.0.
As you can see from that timing report and even in your screenshot, the Lag and ServerWatchdog classes aren't causing any issues whatsoever on your server.
When looking at timings reports, you should narrow the report down to where the server drops below 20 TPS, only recorded once in that report. When you filter it down to just that moment, BossShopPro is the reason for that TPS drop.
In addition to all that, DiscordSRV doesn't really do anything on the server thread to begin with. Thus, DiscordSRV doesn't affect TPS in general, certainly not in this instance.
@Scarsz DiscordSRV may not be the cause of any significant lag, but it's what's causing the most impact across entire profile results with lag spikes. My server is at the point where I can reach a stable 20.0 TPS on 1.14 without any issue. I'm just trying to micro-optimize wherever I can to avoid the short random spikes that happen from time to time.
I have already fixed the issue with BossShopPro's menu refreshing causing an impact, but I appreciate you mentioning it anyways. :)
--
Is there really nothing that can be done to optimize that class further? Or an option to disable monitoring if you don't use the tps placeholder? Checking at an interval of 1 seems excessive. I can run some WarmRoast/Spark profilers for more performance data if needed.
Like I said, there is no performance issue here. I see what you're saying how the Timings report says DiscordSRV is an issue, but you can clearly see in the children of that group, there is no issue whatsoever. Maybe @aikar could have some further input about that discrepancy.
DiscordSRV does very little on the main thread. The connection to Discord is all async, receiving chat messages from both in-game and Discord is async. Group synchronization is async. Even the plugin enabling/disabling is async. There legitimately is nothing that runs on the server thread that would make any sort of performance impact. I've made sure that everything that has a big impact is async wherever possible.
If you look in both of the classes:
- The
Lagclass is just adding a number (the current timestamp) to an array for every game tick, which can be done billions of times per second on modern processors. This is done to get a reading of the server's TPS. It expects a certain amount of those numbers with a specific difference between each value. It then can calculate the TPS based off that. - The
ServerWatchdogclass is it's own thread; it isn't a scheduled sync task. The only thing it does on the main thread is ran once per 20 ticks (~1 second) to give the watchdog it's confidence that the server hasn't died. This is the same way that Spigot's own internal watchdog functions.
Here is some extra profiling data if you'd like to review and extrapolate on any performance measurements out of mere curiosity. Ran it at night with some moderate chat activity, only 11 players online at the time but can measure during peak hours if necessary too. Also updated to Java 12 from Java 8 used in the earlier timings.
Really makes me curious as to why the earlier timings had such a profound measurement.
New measurements are with a recompile of the develop branch as of this commit 4334bd8 with the NPE fix in the voice branch pulled in (not the initial version of voice module commit due to start-up error and in case it was the cause of the problem).
https://timings.aikar.co/?id=74928fd6253940b7b7deff84581b21e3
Spark profile, 300 seconds, all threads: https://sparkprofiler.github.io/#WW5K0P8J0a
Spark profile, 60 seconds, all threads: https://sparkprofiler.github.io/#fS2D6aPJZp
Spark profile, 60 seconds, main thread only: https://sparkprofiler.github.io/#5ckCUbd2kU
My best bet would be that the report was taken so early that timings hadn't ran for long enough to be useful