We test L4 balancers, L7 application delivery controllers, virtual editions and software reverse proxies with the configuration you will run: your certificate and cipher list, cookie persistence, header rewrite, compression and the WAF policy switched on. Emulated users arrive with their own addresses, sessions and keep-alive; an emulated server farm behind the devices slows down, returns errors or stops at a known second. The report holds new connections and handshakes per second, requests per second with every feature on, the spread per server, the users hit by a server failure and the seconds a unit takeover costs. Ports at 1G, 10G and 100G in CloudLAB.
When the figure is needed
The vendor sheet gives L4 connections and L7 requests per second with small objects, no TLS and every feature off. Each stage below asks what the pair does with your TLS profile, your rules and your servers, and ends with a measured value in a report.
Every candidate takes the same users, the same server farm and the same config intent: pools, persistence, TLS profile, rewrite rules and WAF. Vendors see the plan before the first connection and the raw results after the last one.
Ranked table per KPI, feature cost per model, 3–4 weeks for 3 systems
The delivered pair with the production config and the traffic of your busiest hour. Capacity, TLS rate, requests with every feature on, a server hung on purpose and the active unit failed at peak, measured against the capacity plan.
Signed report with pass and fail per case, config exports, from 2 weeks
The acceptance cases run again on the new software, the new WAF policy, the new certificate or the changed health checks. What moved, by how much, and whether the pair still clears the peak plan.
Diff per KPI against the last run, 3 business days
What we test
The users, the server farm and the traffic profile stay the same across the row; the pass criteria do not. The table is the starting point of the plan; your peak and your config set the thresholds.
| Device class | Numbers in the report | Traffic and config on the bench | Typical size |
|---|---|---|---|
| 01L4 load balancer | New and concurrent connections, spread per server, failover with sessions in flight | TCP and UDP clients at your peak connection count, your pools and algorithm, servers taken out mid-run | 10G to 100G, connections as in your peak |
| 02L7 application delivery controller pair in HA | TLS handshakes and requests per second with every feature on, p99, failover and sessions lost | HTTP/1.1 and HTTP/2 users with cookies, your TLS profile, persistence, rewrite, compression, WAF | 10G to 100G per unit, 2 units |
| 03Virtual ADC and cloud load balancer | The same KPIs per instance size and vCPU count, scale-out time, requests per licensed core | Image on the bench hypervisor or in your cloud tenant, the same users and farm as the hardware | 1–20 Gbps per instance |
| 04Software reverse proxy | Requests per second and p99 per worker count, TLS termination cost, config reload under load | Proxy on bench hosts with your config file, objects 1 KB to 512 KB, keep-alive as clients use it | 1–4 hosts, 10G to 100G |
| 05API gateway and ingress controller | Requests per second and p99 per route with auth and rate limits on, the cost of each plugin | API calls with your payloads and tokens, routes from your config, upstreams that slow down | Up to 100k requests per second |
Any vendor, physical, virtual or software. Named test tools are picked for the setup and listed in the report.
Around the pair
A requests-per-second figure only means something with the right things around the device: users who behave like yours, servers that break the way yours will, and the settings you will run
Each emulated user has its own source address, TCP and TLS sessions, cookies and keep-alive, over HTTP/1.1 and HTTP/2. Object sizes from 1 KB to 512 KB and the request mix come from your logs or the app-mix library of our traffic generator. WANemu adds client-side delay and loss on the 1G and 10G links, in beta.
As many emulated servers as your pool has, each with the same content, a fixed answer time and its own counters. Any server slows down, answers 500 or stops at a known second, so the time until the pool reacts and the users caught in between are counted, not guessed.
Pools, persistence, rewrite rules, the TLS profile and the WAF policy come from your export. WAF, compression, caching and TLS re-encryption toward the servers go on one at a time, and each step gets its own requests per second and p99.
Typical scenario
A platform team brings an ADC pair for acceptance before a customer portal moves behind it. The datasheet gives 250k HTTP requests per second with small objects and no TLS. With the production config – TLS termination, cookie persistence, header rewrite, compression and the WAF policy – the pair carries 82k against a peak plan of 100k and fails the case. The counters show two causes: session resumption off, so every client does a full handshake, and the WAF inspecting static objects too. With resumption on and the WAF limited to dynamic paths, as the security team agreed, the rerun on day 7 gives 118k with p99 at 38 ms. The failover case finds a second gap: TLS sessions and persistence records are not synced, so p99 stays above target for 20 s after the switch; with sync on, 4 s.
Composite scenario from projects of this type. Numbers are realistic and not from one client.
What you take away
The report is built for the meeting after the test: the ADC vendor, the application owners and your network team read the same table, with the pass band from the plan next to the measured value
Each value comes with its evidence: generator statistics, ADC counters and pool state, captures and the config export of the run
| KPI | Pass band | Measured | Result |
|---|---|---|---|
| HTTPS requests per second, every feature on | ≥ 100k | 118k | Pass |
| TLS full handshakes per second, your certificate | ≥ 20k | 26k | Pass |
| p99 latency per request at 100k per second | ≤ 50 ms | 38 ms | Pass |
| Server hang to pool down, HTTP check | ≤ 20 s | 15 s | Pass |
| HA failover, traffic flowing again | ≤ 3 s | 1.1 s | Pass |
| p99 back under target after failover | ≤ 5 s | 4 s | Pass with a note |
Where it runs
Hardware pairs ship to CloudLAB or we connect the bench to your lab; virtual editions and software proxies run on the bench hypervisor or in your cloud tenant, and you watch the run through the portal. Users and servers come from commercial traffic generators and from the generator we build ourselves, with stateful traffic at 200 Gbit/s and more on 1G, 10G and 100G ports; native 400G ports are arranged per project. The method is RFC 9411 where it applies and your own cases where it does not.
How a load run goes, step by step Our traffic generator, in beta RFC 9411 and RFC 3511: the benchmark set
Before the brief
See also
Any vendor and any form factor: L4 load balancers, L7 ADC pairs, virtual editions on a hypervisor or in a cloud tenant, software reverse proxies, API gateways and ingress controllers. We need the model or the image, the licence set and an export of your config; the rest is in the plan.
No. The bench emulates the server farm: as many servers as your pool has, your object sizes and answer times, each able to slow down, fail or stop on cue. Your own servers can join the bench instead when the application is part of the question. A test certificate with the same key type and chain length stands in for the production one.
Full and resumed handshakes per second with your certificate and cipher list, then requests per second with TLS terminated and, if you run it, re-encrypted toward the servers. Cipher-by-cipher figures follow our TLS and HTTPS method; on this page they are one line of the plan.
Yes. One server hangs, answers 500 or goes dark at a known second while the pair is at peak. The report gives the time until the pool marks it down, the requests that failed meanwhile and the users who were pinned to it, for each health check you want to compare.
Three options. The pair ships to CloudLAB and goes back after the run. We connect the bench to your lab over a dedicated link. Or, for virtual editions and software proxies, the image runs on the bench hypervisor or in your tenant. The plan names the option and what each side provides.
Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks for one pair and 3–4 weeks for a shortlist of 3. The report has every case with its pass band and the measured value, tables per load step, a timeline per server failure and failover, captures and config exports, plus a one-page summary for the steering meeting.
Scope first, then the quote. The ADC vendor and your application owners can sit in on the brief.
Send the shortlist
Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.
Prefer to chat? Message an engineer on WhatsApp
We use what you send only to answer you. See our Privacy Policy.