High network activity usage after paper#40 build when sending packet(s) to the player's client in a repeating scheduler

montlikadani commented 1 year ago

Timings or Profile link

unrelated

Description of issue

Recently I noticed that the network activity has increased quite a bit. The measurements are done with the built-in Resource Monitor in Windows.

Reproduction steps

Create a plugin with this code, add required dependencies (to get access to the server classes you need to build NMS or paperweight), build and add to your server's plugins

// Create header and footer field with IChatBaseComponent type
getServer().getAsyncScheduler().runAtFixedRate(this, consumer -> {
for (Player player : org.bukkit.Bukkit.getOnlinePlayers()) {
    EntityPlayer entityPlayer = ((org.bukkit.craftbukkit.v1_20_R1.entity.CraftPlayer) player).getHandle();

    // You can send actionbar or any packet which can be repeated like player list
    entityPlayer.connection.send(new PacketPlayOutPlayerListHeaderFooter(header, footer));
}
}, 0, 4, java.util.concurrent.TimeUnit.MILLISECONDS);

Keep the period argument of the asynchronous scheduler between 1 and 100 to achieve the result. (This is currently using Folia's scheduler but it can also be done with Bukkit scheduler)

If you're on Windows search for Resource Monitor and switch to Network tab (if you're on Unix: https://www.baeldung.com/linux/monitor-network-usage#nethogs)
Once you started and joined to the server, search for javaw.exe (this is the client instance where the player is playing now) you can see that the Receive (B/sec) column is increasing and it can reach 1 million+ bytes even higher than any other applications.

This is the usage starting from paper#40 build with the above attached code (the network usage is around 20-30 Mbps):

This is the usage below paper#40 build (tested on 39) with the above attached code (the network usage is around 1-4 Mbps, this was the expectation before):

On idling state when the scheduler of the above code is not running (with only 1 player joined):

These are all tested on the network with speed of 100 Mbps and paper server version 1.20.1

Alternative solution

To make an attempt of fixing this in plugin I reduced the WriteBufferLowWaterMark and WriteBufferHighWaterMark values to 512 (low) and 1024 (high) of the player channel (io.netty.channel.Channel from net.minecraft.network.NetworkManager) to minimise the write buffers to prevent channel write, but this didn't changed anything.

Plugin and Datapack List

no plugins installed except the test plugin

Server config files

https://paste.gg/p/anonymous/82f53961432944c2a4e61ca7ec4c16d7

Paper version

git-Paper-169 (MC: 1.20.1)

Other

No response

MiniDigger commented 1 year ago

just to be sure (since you put 169 as paper version), you are reporting a regression introduced by this commit https://github.com/PaperMC/paper/commit/d6d4c78e7d88f3fcd274bceab1e6b022224096ef (build 40) two months ago? because the code you posted doesnt worth on the version before that commit since that commit brought in the async scheduler.

electronicboy commented 1 year ago

our sus factor is that this is on your side, i.e. you went from sending the header list packet 5 times a second (i.e. every 200ms/4 ticks), to sending it 250 times a seconds, 12.5 times a tick, or, every 4ms

montlikadani commented 1 year ago

nvm, it is on my side, I just need to adjust the period of the scheduler 🤦

PaperMC / Paper