When to use "shareConnections" and "maxConnectionsPerHost(N)"?

Gatling (Open-Source)
1

Gatling version: 3.14.3 (Gatling Enterprise)
Gatling flavor: java kotlin scala javascript typescript
Gatling build tool: maven gradle sbt bundle npm

I’m using Gatling for pure load generation (not realistic user behavior simulation). My goal is to generate high RPS
(e.g., spike of 150K RPS) to test if my API server can handle the load.

My use case:

  • Generate 150K RPS against a single API endpoint
  • Test server capacity under spike load
  • Just need to push high throughput to the server

My questions:

  1. Should I use .shareConnections for this use case?
  2. Should I use .maxConnectionsPerHost(N) with a high value (e.g., 1000)?
  3. Or should I just use Gatling’s default connection management and let HTTP Keep-Alive handle connection reuse?
2

Hello,

Should I use .shareConnections for this use case?

It’s not possible to say as you don’t provide enough information about your use case.
In production, how does the clients of your server behave?

Are they:

  • a huge fleet of user-agents, typically web browsers or mobile apps, that don’t keep connections alive very long? => DON’T use shareConnections
  • a small number of applications, typically load balancers or other server-side applications, that use a connection pool with a very long/infinite keep-alive? => DO use shareConnections

Documentation reference: Gatling HTTP protocol reference - protocol configuration

Should I use .maxConnectionsPerHost(N) with a high value (e.g., 1000)?

maxConnectionsPerHost is only when using resources blocks over HTTP/1.1, so replicate the behavior of web browsers opening multiple connections to speed up static resources fetching.

  1. Or should I just use Gatling’s default connection management and let HTTP Keep-Alive handle connection reuse?

Gatling manages connection keep-alive, as driven by the Connection request and response header. But it’s not related to your question. What matters is the production behavior you want to replicate.

  • web browser-like traffic => 1 connection pool per virtual users => no shareConnections
  • server-to-server traffic => 1 single connection pool shared amongst virtual users => shareConnections
3

For pure throughput testing (100K+ RPS against a single API endpoint), is there any protocol setting that improves raw load generation capacity, or should I just scale injection rate and add more load generators?

4

First, you must figure out if you should be using shareConnections or not based on my above explanations.

Then, there’s no hidden settings that could improve throughput.

If 1 load generator is not enough, typically because your limits are CPU (TLS, payload processing), bandwidth (NIC) or connections (kernel), you have to either scale up (more powerful load generator) or scale out (more load generators).