Use fewer event loops when using io_uring as transport
#5089
Conversation
Motivation: `io_uring` is known to have much smaller system call overhead than other transport types such as NIO, `epoll` and Kqueue. Therefore, we should use fewer event loop threads when using `io_uring`. Modifications: - Changed `FlagsProvider.numCommonWorkers()` to require `TransportType` - Made `DefaultFlagsProvider.numCommonWorkers()` not double the number of CPU cores when the current transport type is `IO_URING` Result: - A user doesn't have to manually specify the optimal event loop count when using `io_uring`.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #5089 +/- ##
============================================
- Coverage 74.19% 74.19% -0.01%
- Complexity 19469 19470 +1
============================================
Files 1672 1672
Lines 71749 71752 +3
Branches 9189 9190 +1
============================================
Hits 53237 53237
- Misses 14186 14187 +1
- Partials 4326 4328 +2
☔ View full report in Codecov by Sentry. |
| public Integer numCommonWorkers() { | ||
| final int defaultNumCpuCores = Runtime.getRuntime().availableProcessors(); | ||
| return defaultNumCpuCores * 2; | ||
| public Integer numCommonWorkers(TransportType transportType) { |
There was a problem hiding this comment.
Optional) There is a similar case where a flag depends on another flag to resolve the final value like this. #5029 (comment)
What do you think of a getter method for the composed FlagsProvider and set it to SystemPropertyFlagsProvider?
For example:
interface FlagsProvider {
// Needs a better name.
default FlagsProvider composedFlagsProvider() { return null; }
}
...
SystemPropertyFlagsProvider systemProvider = new SystemPropertyFlagsProvider();
final List<FlagsProvider> flagsProviders = ServiceLoader.load(...);
flagsProviders.add(0, systemProvider);
flagsProviders.add(DefaultFlagsProvider.INSTANCE);
systemProvider.setComposedProvider(flagsProviders);
public Integer numCommonWorkers() {
if (composedFlagsProvider().transportType() == TransportType.IO_URING) {
...
}
}One concern is the circular reference between flags. If it looks overkill or dangerous to use, feel free to ignore this comment.
There was a problem hiding this comment.
It sounds a little bit dangerous to me because it's fairly easy to trigger circular dependency as you said. We could revisit this when we end up with the situation that really needs this.
Motivation:
io_uringis known to have much smaller system call overhead than othertransport types such as NIO,
epolland Kqueue. Therefore, we shoulduse fewer event loop threads when using
io_uring.Modifications:
FlagsProvider.numCommonWorkers()to requireTransportTypeDefaultFlagsProvider.numCommonWorkers()not double the numberof CPU cores when the current transport type is
IO_URINGResult:
when using
io_uring.