First look at specialized network compression threads #5805
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
dktapps
added
Category: Core
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 |
Joshy3282
added a commit
to Joshy3282/PocketMine-MP
that referenced
this pull request
Oct 2, 2024
Joshy3282
added a commit
to Joshy3282/PocketMine-MP
that referenced
this pull request
Oct 2, 2024
This reverts commit 6a25e66
dktapps
added
Status: Incomplete
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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-compressioninpocketmine.ymlis now ignored, as isnetwork.async-compression-threshold.network.compression-threadshas been added, with a default of0(for now). This can be set to a positive integer orautoin 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.