Services / Load testing
TestsWe design and run k6 load tests for your application
We design, run, and report k6 load tests. We start from the application: paths, share of traffic, SLO, environment, and test data. Then we stand up a harness in the repo, dashboards, and a baseline. We run load, spike, and soak. We leave a finding for architecture: index, cache, more pods, a different limit, or cost.
How it fits together
From the traffic model to a finding for architecture
First we understand the application paths and the SLO. On that basis we put together k6, Grafana, the cluster, and a network view. The generator, the dashboard, and the cluster are what we use for that work every day.
- The first performance test and a failover exercise are two separate dates.
- A software house can get the same harness on the next client, with a change of traffic model.
We design a k6 scenario from your application traffic
k6, and JMeter where it already exists, gets a model: login, checkout, webhook, nightly report. Spike, soak, and stress are separate sessions. The harness stays in the repo, it can be run before a peak.
Model
Path share from production. Think time, cache, warmup. The model is what makes the test comparable.
Types
Load, spike, soak, stress. Soak catches a leak after hours, after a short run has already passed.
Gate
SLO in the test: p95, error, saturation. The pipeline fails when the budget breaks.
Repeat
The same script on a software house client staging and before a campaign.
We watch p95, errors, and saturation during the test
We look at API p95, database locks, CPU, GC, and queue length together with the k6 run. The decision is an index, a cache, more pods, or a different limit, from the same timeline.
Correlation
VU, latency, error, and saturation on one timeline.
Layers
App, database, cache, queue, storage. The bottleneck has a name.
Comparison
Before the change and after. The same scenario, a different build.
Report
For engineering and for product: what breaks at which traffic.
We check whether the cluster holds the load
HPA, PDB, and requests show under load. The test shows whether you hit a CPU limit, a connection pool, or IPs on the node. Capacity planning comes from measurement.
Limits
CPU throttle looks like a slow API. In the test you see it.
Scale
HPA, node pool, PDB. Whether a new pod comes up before p95 runs away.
Neighbors
Noisy neighbor and namespace limit. A test on a shared cluster has separate findings.
Cost
A larger node group without need is a FinOps finding, next to the test result.
We check the path when the bottleneck is the link, DNS, or a peer
ntopng and edge metrics show whether the test hits the application, or the firewall, NAT, or the link. Chaos and failover are a separate session. We keep them off the first performance measurement.
Path
Generator, edge, load balancer, pod. Every latency jump has a layer.
Applications
TLS, database, queue. Traffic classification suggests what to scale.
Failover
A separate session: AZ loss, database restart, DNS switch.
Boundary
A DDoS test is a different goal and a different playbook from a product load test.
How we work
From the client application to a decision
We start from analytics and SLO. Then we stand up the harness and observation. We run load, spike, and soak. We leave a finding for architecture, and a retest after the change.
- Application We check paths, share, SLO, environment, and test data. That gives the scenario and the sessions.
- Harness We stand up k6 in CI or a steered session, with dashboards and a baseline.
- Measurement We run load, spike, and soak. The bottleneck gets a layer name.
- Decision We leave a change of architecture, limit, or cost, then a retest on the same scenario.
Talk
We will discuss the traffic scenario and SLO
On that basis we will prepare a scope: harness, sessions, and a report.
Contact us