Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple scaling issues #3

Open
RaynLegends opened this issue Jan 22, 2021 · 2 comments
Open

Multiple scaling issues #3

RaynLegends opened this issue Jan 22, 2021 · 2 comments
Labels

Comments

@RaynLegends
Copy link

The plugin as it currently is does not scale well when considering a large number of players.
There's no need to do cpu-intensive operations like Player#sendMessage while more optimized options are available, and currently each player is processed sequentially.

Proposal 1 - Packets

I suggest implementing sending the join message in a fully-asynchronous manner using packets.
While this requires handling code for different versions of the underlying server implementation, it would greatly reduce overhead by avoiding calling API methods that then need to initialize a new message packet for every player, since we can initialize the packet first and then iterate and send it.

Proposal 2 - Parallelization

The stream() call should be followed by parallel(), or even better we should implement our own workload handling to process the players online, maybe even caching Bukkit#getOnlinePlayers().

Motivation and Context

The current onJoin/onQuit algorithm is O(n), since it needs to iterate over every player sequentially.
By calling parallel(), we allow the stream to potentially consume the players in O(1).
Player#sendMessage calls CraftPlayer#sendRawMessage, which creates a new PacketPlayOutChat and also converts the "legacy" string message to a "modern" IChatBaseComponent message.

See: https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/browse/src/main/java/org/bukkit/craftbukkit/entity/CraftPlayer.java

@conclube
Copy link
Owner

This is a genius idea! I will be implementing this by instant.

@solonovamax
Copy link

have you ever thought of delegating it all to a ThreadPoolExecutor?

Then you can instantiate 999 threads and it will handle it all concurrently!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants