Netty vs. Java HttpClient: Balancing Concurrency and SSL Reliability in Gatling Deployments

Answer

For reliable deployment diagnostics while keeping acceptable performance, use the Java HttpClient unless you can prove that Netty’s higher concurrency is required and you can retain SSL error visibility.

Confirmed facts

• Disabling SSL verification in Netty (by supplying an insecure trust manager) causes SSL handshake failures to be logged as generic connection exceptions (e.g., ConnectException or ClosedChannelException) in Gatling execution logs, hiding the specific SSL error.
• The Java HttpClient validates certificates by default and logs an SSLHandshakeException with certificate details, making SSL failures explicit.
• Enabling a global “ignore‑ssl‑errors” flag via a custom trust manager does not suppress Gatling’s request/response logging; full headers, payloads, status codes and bodies remain recorded.
• In typical load‑test scenarios with keep‑alive enabled, Netty delivers roughly 10‑30 % higher requests‑per‑second than Java HttpClient because its fully asynchronous pipeline incurs less thread‑parking overhead.

Likely explanation

The throughput advantage of Netty stems from its event‑loop driven, non‑blocking I/O, whereas Java HttpClient (especially version 11+) uses a hybrid blocking/asynchronous model that adds a small overhead during TLS handshake verification. When SSL verification is disabled, Netty swallows the verification error, so the only trace left in the logs is a generic I/O failure, which makes it difficult to distinguish a certificate problem from a network problem.

Steps for this case

1. Decide whether SSL verification can remain enabled. If the target servers use certificates from a public CA or you can add the internal CA to the JVM truststore, keep verification on.
2. If verification must be disabled (e.g., testing against self‑signed dev endpoints), configure Netty with a custom trust manager that logs the SSL error before accepting the certificate, or switch to Java HttpClient and import the self‑signed cert into a dedicated truststore.
3. Set Gatling’s HTTP client in gatling.conf:

   http {
     client = java   # or netty
     sslContext {
       # trustStore = "./truststore.jks"
       # trustStorePassword = "changeit"
     }
   }
   

4. Run a short sanity check at the intended concurrency level (e.g., 200 virtual users) and compare the requests‑per‑second reported in the Gatling summary.
5. If the Netty run shows a >15 % throughput gain and the logs still contain the SSL error (via the custom trust manager), you may keep Netty; otherwise prefer Java HttpClient for clearer diagnostics.

Missing diagnostic detail

Are the endpoints using internally‑issued or self‑signed certificates? Knowing this determines whether adding the cert to a truststore is feasible, which would let you keep Netty’s performance advantage without sacrificing SSL error visibility.