4 ms·
For those that want the "Quick WTF?!" it is because: * With modern operating systems, idle threads are practically free. * Managing non-contending threads is ex
by rkalla 16y ago
For those that want the "Quick WTF?!" it is because:
* With modern operating systems, idle threads are practically free.
* Managing non-contending threads is extremely inexpensive now.
* Multi-core systems.
* Selectors and state-restore used by asynchronous NIO libraries in high-load environments is more expensive than waking up and putting to sleep threads.
You mix all that together and you get a new appreciation for java.io.
- jbooth 16y agoThe missing detail from all of these, of course, is that transferTo doesn't work with blocking I/O. You need to use a selector on WRITE to the client socket to make sure you're actually allowed to transfer bytes. Given that transferTo involves zero-copy (always faster than copying to buffers), a mix of the two approaches is usually best.
- rkalla 16y agojbooth, Interesting post -- I don't know if that is something Paul evaluated. What mix/ratio would you propose? Something like 1:10 threads:selector/connections?
- jbooth 16y agoWell, if you're getting into that, you're far enough down into the rabbit hole of optimization that you probably have a reason for being there and some business specific logic that would drive some of your specific tunings.. I'd generally recommend a selector identifying sockets that are ok for write and then delegating to a caching thread pool to handle actual transferTos. If that select loop becomes your bottleneck, you can of course horizontally scale that and have a set of selectors, striping the register()s across them to get less lock contention and having them all feed into the caching threadpool.