akka-io: fixed #1225 - High CPU load using the Akka.IO TCP server #1236
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
rogeralsing
added a commit
that referenced
this pull request
Aug 11, 2015
akka-io: fixed #1225 - High CPU load using the Akka.IO TCP server
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.
TL;DR; This PR resolve issue #1225.
The JVM socket selector will block until one socket is selected, or when wakeup is called. The behavior in JVM Akka is to block indefinitely until a socket is selected, or whenever a socket interest is added/removed to wake-up the selector and then select again.
In .NET sockets there is unfortunately no way I'm aware of to wake-up the Socket.Select method. The high CPU usage here was caused because we never blocked on Select.
I've changed the Select to block for 1 millisecond (the lowest timespan), which (in my testing at least) changed the idle CPU usage from 15% to 0%. The compromise is of course that some socket operation might wait a average of 0.5 ms, before they complete. I still have to do detailed measurement on the performance impact, but from my initial testing is seems reasonable.
The longer term solution is to switch to completely asynchronous sockets. I have a working version of this, but it breaks most TcpConnectionSpec tests - which are white box tests.