Which connection states must be counted when sizing Tomcat maxConnections for production traffic?

In a Tomcat 8.5+ NIO or NIO2 deployment, the connector attribute maxConnections limits the total number of sockets the connector will accept and process. Because idle keep-alive connections remain counted against that ceiling, a configuration that behaves correctly under light local traffic can exhaust the pool in production when clients maintain persistent connections between sparse requests. The uncertainty is whether the attribute should be sized only for expected concurrent active requests, or whether it must also reserve capacity for idle keep-alive sockets; published guidance often disagrees on this point.

The decision is complicated by version-specific defaults and connector differences. Tomcat 10.x changed the NIO2 default maxConnections from Integer.MAX_VALUE to 8192, which can surprise teams upgrading from earlier releases. Raising the limit also interacts with operating-system file-descriptor caps, and the APR/native connector does not necessarily treat idle connections the same way as NIO or NIO2. Without a clear rule, operators must guess whether to match maxThreads, sum active and idle peaks, or leave the default and adjust connectionTimeout instead.

Which sizing model should govern maxConnections for a production NIO2 connector: peak active requests only, or peak active plus idle keep-alive sockets? How does the correct calculation change when upgrading from a pre-10.x Tomcat with an effectively unlimited default to the 8192 default? Is there a documented, connector-specific rule that reconciles the NIO/NIO2 counting behavior with the different treatment in APR/native?