-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
First look at specialized network compression threads #5805
base: minor-next
Are you sure you want to change the base?
Conversation
closes #5641 This has been mostly tested on Windows so far, where it offers substantial performance gains for compression. On *nix, the performance advantage is smaller, since there's less overhead to creating new AsyncTask instances; however, the performance benefit is still clearly visible. There are still some wrinkles to iron out, such as the dumb algorithm used for cycling through threads which wastes memory on small servers, but this change is mainly aimed at large servers, where the benefit will be clearly apparent. In practice, this should reduce main thread CPU load by 10-20% on some of the largest servers, offering a large amount of headroom for increased player counts.
CompressBatchTask is kept for internal testing for now
Related to: #1161 |
Yes, I'd actually forgotten about that issue. Though this change doesn't solve #1161 entirely. |
User reports suggest that this change may offer a substantial performance improvement to certain types of servers. |
this prevents accidental access to shared properties, which would cost performance.
This is potentially affected by pmmp/ext-pmmpthread#42, but profiling suggests that the issue should be minimal for the situations that the ThreadSafeArrays used here are subjected to |
This should probably include some kind of GC mechanism to dispose of idle pools and free up memory |
This reverts commit 6a25e66
Introduction
As described in #5641, using AsyncTasks for compression is no longer cost-effective, due to the large overhead of creating an AsyncTask and scheduling it.
This PR introduces a specialized thread pool for network compression, which once again makes threaded compression practical.
It also uses Snooze to minimize latency.
The current implementation isn't optimal, but it's much faster than using AsyncTasks.
Relevant issues
#5641
Changes
API changes
No public API changes - this is all network internals.
Behavioural changes
network.async-compression
inpocketmine.yml
is now ignored, as isnetwork.async-compression-threshold
.network.compression-threads
has been added, with a default of0
(for now). This can be set to a positive integer orauto
in a similar manner tosettings.async-workers
.Backwards compatibility
Fully backwards compatible.
Follow-up
Explore whether chunk prepare and compression needs similar treatment. Chunk handling bypasses the usual systems using
ChunkRequestTask
, which is not modified here.Tests
This has been mostly playtested and benchmarked on Windows. Unit tests TBD.