Targets
- Latency percentiles per key transaction
- Throughput at peak
- An error rate budget
- Taken from your SLOs, or set with you if none exist
Performance Testing
Load, stress and performance testing services
A load test that fires random traffic at a staging server tells you little about launch day. Agnotic Technologies runs performance tests that answer a release question, with targets taken from your service level objectives and load shaped like your real traffic.
Targets from SLOsWorkload from real trafficLoad, stress, spike and soakBottlenecks traced to a cause
Trusted by global innovators
Performance testing
What is performance testing, and what should it answer?
Performance testing is measuring how a system behaves under a defined load, so you know before release whether it meets its latency, throughput and error targets. Agnotic Technologies provides performance and load testing services that start from a release question, model real traffic, run the right test type and trace each bottleneck to its cause.
We do not promise response times or publish benchmark numbers. The targets are yours, set from your service level objectives, and the report says whether the system met them.
Functional test execution sits with our QA and testing services, and attack traffic such as DDoS simulation belongs to security testing. This page is about speed, capacity and stability under load.
Decision table
Which performance test answers your release question?
We start from the question, then pick the test type, the load shape and what to measure.
| Question you need answered | Test type | Load shape | What we measure |
|---|---|---|---|
| Do the scripts and monitoring work at all? | Smoke test | A few virtual users for a few minutes | Errors, script correctness, monitoring in place |
| Will it handle a normal busy day? | Average-load test | Ramp to expected peak-hour traffic, hold, ramp down | Latency percentiles, throughput and error rate against the SLO |
| Will it handle launch day or a seasonal peak? | Stress test | Ramp above the expected peak and hold | Where percentiles start to climb and which resource saturates first |
| Can it absorb a sudden burst, such as a campaign email? | Spike test | A jump from normal to several times normal in seconds | Errors during the jump, autoscaling reaction, recovery |
| Does it degrade over hours? | Soak test | Normal load held for hours | Memory growth, connection leaks, slow drift in latency |
| Where exactly does it break? | Breakpoint test | Load raised in steps until a target fails | The capacity limit and the component that fails first |
Most releases need a smoke test, an average-load test and one of the others. We choose from the question, not from habit.
How a test is built
How do we build a performance test that reflects real use?
Five parts, built in this order, so the numbers at the end mean something.
Workload model
- Transaction mix from production logs or analytics
- Arrival rate, not only user count
- Think times and session lengths
- Peak hour and peak day shapes
Environment and data
- Production-like sizing and configuration
- Data volume close to production
- Third-party services stubbed or tested by agreement
- Load generators outside the system under test
Run and observe
- Scripts in k6, JMeter or Gatling
- Server metrics, traces and logs captured during the run
- Each run tagged with its build and configuration
Analyse
- Percentiles against targets
- Saturation signals: CPU, memory, pools, queues
- Bottleneck traced to code, query or configuration
Reading results
How do we report performance test results?
What every test report from us contains.
- Latency as 50th, 95th and 99th percentiles for each key transaction, never an average alone
- Throughput and error rate beside latency, because a fast error is still an error
- Saturation signals for each tier: CPU, memory, connection pools, thread pools and queue depth
- The first resource to saturate, which is the bottleneck to fix first
- A pass or fail against each target, with the build and configuration that was tested
- Recommended fixes in order of expected effect, with the evidence for each
Failure points
Why do performance test results mislead?
Mistakes that make a test look better or worse than production, and how we avoid them.
Challenge
The test environment is a fraction of production, and results are scaled up by guesswork.
Agnotic approach
We test on production-like sizing, or state clearly which components were smaller and what that limits.
Challenge
Test data is tiny, so every query hits a warm cache.
Agnotic approach
Data volume and distribution are seeded close to production before any timed run.
Challenge
The load generator runs out of CPU before the system does.
Agnotic approach
Generators are monitored too, and a run is discarded if they saturate.
Challenge
User count is fixed but arrival rate is not, so load drops when the system slows.
Agnotic approach
We drive tests by arrival rate, so a slow system faces the same demand real users would create.
Challenge
One number, the average, hides the slow requests.
Agnotic approach
Reports show percentiles and name the slowest transactions.
Challenge
Tests run once before launch and never again.
Agnotic approach
A short check on key transactions runs in CI, so a regression shows up on the change that caused it.
When to test
When do teams ask for performance testing?
The release questions we are asked most often.
Product launch
Will the first day's traffic work, and what breaks first if it is bigger than planned.
Seasonal peak
Retail sales, enrolment windows or tax season, tested at the expected peak and above it.
Architecture change
A new database, a cloud migration or a move to services, tested against the old baseline.
Contract response time terms
When a customer contract names response times, we test against those exact terms.
Recurring slow periods
Intermittent slowdowns in production, reproduced under load and traced to a cause.
Tools
Which tools do we use for load and performance testing?
We pick tools to fit your team and protocols; the workload model matters more than the tool.
Grafana k6Apache JMeterGatlingOpenTelemetrySLOs
Facts and sources
Facts behind performance testing
Published guidance and tool documentation, each linked to its primary source.
Google's Site Reliability Engineering book warns that a simple average can hide tail latency and recommends percentiles: a high percentile such as the 99th shows a plausible worst case, while the 50th shows the typical case.
Source: Google SRE book, chapter 4: Service Level ObjectivesThe same chapter defines a service level objective as a target value or range of values for a service level that is measured by a service level indicator.
Source: Google SRE book, chapter 4: Service Level ObjectivesGrafana k6 documentation names six load test types, smoke, average-load, stress, soak, spike and breakpoint, and notes that no single test can uncover all issues.
Source: Grafana k6 documentation: load test typesApache JMeter is open source, pure Java software designed to load test functional behavior and measure performance; it was first built for web applications and later extended to other test functions.
Source: Apache JMeter project site
Engagement
How does a performance testing engagement run?
Three stages, each ending with something you can act on.
1.
Agree the question and targets
We agree what the test must answer, the key transactions and the targets, and check access to traffic data.
Scope2.
Build the model and scripts
We build the workload model, scripts, test data and monitoring, then prove them with a smoke test.
Build3.
Run, analyse and retest
We run the tests, find the bottleneck, and retest after your team or ours applies the fix.
TestScope and cost
What drives the cost of performance testing?
There is no price list; the size of a performance engagement comes from these factors, agreed on the scoping call.
Key transactions
How many user journeys and APIs the workload model must cover.
Environment
Whether a production-like environment exists or has to be built for the test.
Test data
How much data has to be generated or masked to match production volume.
Third-party dependencies
Payment, identity or partner services that must be stubbed or tested by agreement.
Test types
How many of load, stress, spike, soak and breakpoint tests the release needs.
Fixing work
Whether our engineers also tune and fix the bottlenecks, or your team does.
Frequently Asked Questions
We do not publish prices. Cost depends on the number of key transactions, the environment, test data, third-party dependencies, the test types needed and whether we also fix what we find. A written proposal follows the scoping call, with the test types and environments listed.
A load test checks the system at the traffic you expect and compares the results with your targets. A stress test pushes beyond that to find where performance degrades and which component fails first.
Sometimes, with care: low-rate synthetic checks, or tests in a quiet window with agreed limits and a stop switch. For high loads we prefer a production-like environment, because a test that harms real users is not worth its data.
Whichever fits your team and protocols. k6 suits teams who want scripts in the codebase next to the application; JMeter suits teams with existing JMeter plans or protocols it supports well. The workload model matters more than the tool.
Yes, if you want us to. Our engineers can tune queries, caching, pools and code, then retest. Or we hand your team the evidence and retest after their fix.
Yes. A short test on a few key transactions runs on each merge or nightly, with thresholds that fail the build on a regression. Full stress and soak tests stay as planned runs.
Your release question, any SLOs you have, access to production traffic data or analytics, an environment we are allowed to load and a contact for each system the test touches.