Why is Gatling the best load generation engine? | Gatling

Why is Gatling the best load generation engine?

The high-performance architecture behind Gatling's load generation engine, and why it holds up when everything else starts dropping requests.

Keep this datasheet

Get the full datasheet in your inbox

Everything on this page, as a PDF, for sharing with your team or your architecture review.

Check your inbox We just sent the technical datasheet to your email.

The problem

Common blockers to achieving your load testing goals

What engineering teams consistently run into when trying to run reliable, high-performance load tests.

Test architectures are complex to build and maintain

Standing up a reliable load testing environment takes heavy engineering effort.

blockInability to simulate real concurrency due to blocking or thread-per-user models
link_offFragile distributed setups that break under CPU, network, or configuration drift
trending_downMetrics pipelines that drop samples or flatten peaks when throughput increases
tuneHigh operational load just to keep generators and environments aligned

Even existing setups often fail to scale

Most engines saturate compute, memory, or sockets long before realistic traffic.

speedLimited scalability caused by thread-per-user architectures
memoryCPU exhaustion before real concurrency is reached
boltUnpredictable throughput under bursts or TLS-heavy traffic
warningInability to reach peak-load scenarios without generator failures

Large-scale tests become too expensive to run

Inefficient engines need too many machines for meaningful load.

paymentsLarge load generator fleets driving up cloud compute costs
storageHigh CPU, memory, and bandwidth consumption per virtual user
trending_upUnpredictable test costs as traffic scales
hourglass_emptyLong warm-up/cool-down periods that waste infrastructure time

Modern environments need flexible, secure deployment

Systems now span SaaS, Kubernetes, private VPCs, and on-prem, testing must adapt.

securityDifficulty running tests behind firewalls or inside private networks
hubLimited support for hybrid, SaaS-controlled, self-managed setups
swap_horizNo way to run generators close to microservices for low-latency tests
verified_userLack of secure, compliance-friendly options for regulated workloads

Inside the engine

The Gatling load generation architecture

Gatling Enterprise Edition is powered by one of the most scalable, resource-efficient, and battle-tested load generation architectures in the industry.

While most legacy tools rely on heavy, thread-per-user architectures, Gatling's engine is fully asynchronous, event-driven, and optimized for massive concurrency, simulating millions of virtual users and sustaining extreme throughput with far fewer machines than traditional solutions.

Engineering detail

Operating at the physical limits of a machine

Why Gatling's engine delivers real concurrency, predictable performance, and extreme throughput with fewer machines.

Physical constraint What limits it How Gatling reaches max capacity

~64,000 concurrent sockets per target server

A TCP connection is a quadruplet (local IP, local port, target IP, target port). With one local IP, a machine can open about 64,000 concurrent connections to the same server.

Non-blocking I/O. Gatling's Netty-based engine uses non-blocking I/O to fully leverage available sockets and sustain maximum concurrency.

60-second port reuse delay

The Linux kernel enforces a ~60s TIME_WAIT before reusing closed TCP ports, a hard-coded safeguard against duplicate packet collisions.

Persistent connections. Gatling reuses connections within virtual user sessions to minimize reconnections and keep throughput steady.

TLS handshake CPU cost

Establishing HTTPS connections requires CPU-intensive key exchange and validation, which grows heavier with stronger ciphers.

BoringSSL. Gatling integrates BoringSSL for efficient, secure TLS operations and optimized session reuse.

Variable resource cost per request

CPU, memory, and bandwidth consumption vary with payload size, response complexity, and scenario design.

Async scheduling. Gatling's asynchronous scheduler balances I/O and computation to maintain high concurrency under real-world loads.

What you can achieve

Simulate millions of virtual users, across any architecture

Monoliths, APIs, microservices, Kubernetes clusters, and globally distributed streaming platforms, all handled by the same engine.

60,000

Concurrent virtual users per load generator

Generates millions of requests per second for any kind of architecture

300,000

Requests per second on each load generator

Streaming leaders generate massive traffic to prepare for record-breaking peaks

What customers reach with Gatling Enterprise Edition

200+

Automated tests running in parallel, 24/7

100+

Load generators running simultaneously

5M+

Concurrent virtual users with 20 load generators

Flexible by design

Deployment models for load generation

Gatling Enterprise Edition adapts to any network, security, or infrastructure context.

01 / MANAGED

Gatling-managed load generators

Hosted and operated by Gatling on AWS, pre-configured for optimal performance. Default instance: c6i.xlarge (4 vCPU).

Capability

Up to 3 million virtual users with 50 concurrent load generators, configurable to 100–200, with validation to avoid cloud provider security limits.

02 / SELF-MANAGED

Self-managed load generators

Deploy and manage your own injectors in AWS, Azure, GCP, Kubernetes, OpenShift, or on-premises. Full control over sizing, scaling, and security.

Capability

Unlimited scaling, constrained only by your own infrastructure quotas and compute capacity.

Whichever model you choose, test orchestration, reporting, data aggregation, and scenario execution stay fully centralized within Gatling Enterprise Edition.

Never alone

Premium support for high-scale testing

Gatling Enterprise Edition includes enterprise-grade support designed for mission-critical load testing.

architecture

Architecture & topology

Recommendations tailored to your systems.

trending_up

Scenario & performance strategy

Design guidance from testing experts.

bug_report

Debugging

Help finding system bottlenecks.

tune

High-scale configuration

Guidance for demanding test setups.

monitor_heart

Injector health monitoring

Ongoing monitoring & troubleshooting.

verified

Best practices

JVM warmup, TLS optimization, scaling patterns.

Find your fit

How to choose your load generation configuration

Whether your services are public, firewalled, or fully isolated on-premises, there's a deployment model built for it.

Endpoint infrastructure	Testing requirement	Recommended solution
Public services Internet-exposed	No strict firewall rules or rate limits	Gatling-managed load generatorsFully managed on AWS
Public services with firewall / DDoS protection	Client must allow Gatling traffic through security layers	Gatling-managed with dedicated IPFixed IPs for whitelisting
Cloud-native or microservices environments	Need load close to the application to minimize latency	Private locationsCloud-managed
Secure or regulated environments	Sensitive data, secret keys, or regulated credential handling	Private locationsCloud-managed
Private services Behind firewalls, no direct internet access	Application or API can't be reached from public networks	Private locationsCloud-managed
No access to public cloud providers On-prem, managed datacenters	Fully isolated infrastructure	Private locationsDedicated machines

All private-location options deploy across AWS, Azure, GCP, Kubernetes, or OpenShift, with full control over the entire environment.

Ready to evaluate Enterprise Edition?

Whether you're scaling APIs, migrating to the cloud, or handling flash-traffic spikes, Gatling helps you deliver fast, reliable performance.

Talk to an expert