[#1935] Don't create CPU*2 "New I/O worker" threads for unused ports #1327
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.
This change avoids creating
ServerBootstrap
objects which are never bound to a port (for example, not creating the HTTPS server if the application doesn't have ahttps.port
configured).The change is simple, it only moves the code which instantiates these objects into the following if statement. Netty creates 2*(number of processor) "New I/O worker" threads when a
NioServerSocketChannelFactory
object is created, so this change avoids creating lots of threads that the application never uses.For example, on a machine with 16 CPUs, this eliminates the creation of 32 threads that would otherwise exist for the lifetime of the Play server and never execute. The benefit for eliminating these threads:
Background Context
The Play! code has been like this since at least 1.2.7, but the excess thread creation didn't exist until 1.3.0 when an update to the netty library changed the location from which Netty creates the threads.
In my organization, we run dozens of Play! applications on a machine with many CPUs and each of these Play! applications only has
http.port
configured (nohttps.port
). End users access these Play! servers through a reverse proxy that provides the HTTPS connection. For us, the reduction in thread usage is noticeable.