Tomcat NIO vs APR/native connector: when is native throughput worth the portability cost?

We run Tomcat on both Linux and Windows hosts and want to pick a single connector strategy for a high-traffic HTTP endpoint. The documentation describes NIO as the portable pure-Java default, while APR/native can use platform-native pollers and OpenSSL-style TLS integration but requires matching native libraries per OS and packaging.

Our constraint is maximizing sustained throughput without losing cross-platform deployability. We have not yet measured where our bottleneck actually sits — keep-alive handling, executor thread limits, TLS overhead, application latency, and the fronting reverse proxy could all dominate connector choice. We also know connector behavior is version-sensitive, so assumptions from older APR-based deployments may not hold on current Tomcat releases that emphasize NIO/NIO2.

Assume a recent Tomcat release with identical JDK, TLS settings, and executor configuration on both connector variants.

• What measurement criteria (throughput, latency percentiles, CPU, connection states) should decide whether an observed APR advantage is large enough to justify native binaries and harder rollback?
• How should we confirm from startup logs or JMX that the intended connector is actually active rather than silently falling back?
• If APR is unavailable on one target OS, is standardizing on NIO everywhere preferable to a mixed-connector fleet?