Question
Netty vs. Java HttpClient: Balancing Concurrency and SSL Reliability in Gatling Deployments
Ira Dey
0 reputation · 09 Oct 2024, 15:44 UTC
86.7K views0
Netty vs. Java HttpClient: Balancing Concurrency and SSL Reliability in Gatling Deployments
When a Gatling simulation fails to deploy, the execution logs are the primary source for diagnosing the root cause. A core decision is whether to use the Netty HTTP client, which offers higher concurrency but requires explicit SSL configuration, or the Java HttpClient, which simplifies SSL handling at the cost of throughput.
Key Constraint: SSL Verification
Netty’s default settings can silently drop SSL errors, causing deployment failures to surface only as generic connection errors in the logs. The Java HttpClient automatically validates certificates, making SSL failures explicit but potentially slowing request rates.
Unresolved Decision
Which client should be chosen to maintain reliable deployment diagnostics while preserving acceptable performance?
Specific Questions
- How does disabling SSL verification in Netty affect the visibility of failed requests in the Gatling execution logs?
- What measurable throughput difference does switching to the Java HttpClient introduce in a typical deployment scenario?
- Can a global ‘ignore‑ssl‑errors’ flag be enabled without suppressing detailed request/response entries that are crucial for debugging?
