Services / Load testing
PerformanceWe know where the system breaks, before production does
k6 replays traffic. Grafana shows p95, errors, and saturation. Kubernetes says whether limit and autoscaling hold. ntopng is visible when the bottleneck is in the network, not in the application. The result is an architecture decision, not only a chart.
How it fits together
Load, observation, capacity, network
A generator without a dashboard does not say what to scale. We put k6, Grafana, the cluster, and a network view into one finding for architecture.
- 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.
A scenario from analytics, not from a random RPS number
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. Without this the test lies.
Types
Load, spike, soak, stress. Soak catches a leak after hours, not after two minutes.
Gate
SLO in the test: p95, error, saturation. Fail the pipeline when the budget breaks.
Repeat
The same script on a software house client staging and before a campaign.
A chart tied to application, database, and queue
k6 without observation is RPS in a vacuum. We look at API p95, database locks, CPU, GC, queue length. The decision: index, cache, more pods, a different limit, not adding instances blindly.
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.
Autoscaling and limits under traffic, not on a slide
HPA, PDB, and requests show only 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, not a test success.
When the link, DNS, or peer breaks, not the code
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 do not mix them with 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 not a product load test. A different goal, a different playbook.
Operations
From traffic model to a decision
First analytics and SLO. Then harness and observation. Finally soak, a finding, and optional chaos.
- Model Paths, share, SLO, environment, test data.
- Harness k6 in CI or a steered session, dashboards, baseline.
- Measurement Load, spike, soak. A bottleneck with a layer name.
- Decision A change of architecture, limit, or cost. A retest.
Talk
We will discuss the traffic scenario and SLO
On that basis we will prepare a harness, sessions, and a report for architecture.
Contact us