Stress Testing: Finding Breaking Point and Load Limits

Your site crashes under a flash crowd? We pinpoint the breaking point before your users do. Stress testing is a load test that deliberately exceeds normal peak values. For an e‑commerce store before a sale, we simulate up to 10,000 virtual users to see at which RPS errors appear.

Stress tests reveal bottlenecks: database, CPU, memory, network. The output is concrete numbers: p95 latency, error rate, maximum RPS. This prevents downtime and can save up to 40% of infrastructure budget. Based on our practice (over 100 projects), clients cut server costs by 30–50% after optimizing from stress test results. For instance, one e-commerce client saved $12,000 per month on AWS costs after we identified and fixed a database bottleneck. Typical stress test projects start at $2,000 and can go up to $10,000 depending on complexity.

Problems We Solve

Sudden latency spikes. During a campaign, response times jump from 200ms to 5s. We identify the exact bottleneck – slow database queries, misconfigured caches, or insufficient connection pools.

Out‑of‑memory crashes. Under moderate load, the application dies with ENOMEM. We trace memory leaks and fix process limits.

Slow recovery after load. Even if the system survives a peak, a slow return to normal (over 2 minutes) indicates poor connection pool settings or memory leaks. We always test recovery.

How We Do It

We use k6 – a tool that consumes 5x fewer resources than Apache JMeter and outperforms it by 5x. k6 is written in Go and supports JavaScript scripts, making it ideal for CI/CD. The process has four stages:

1. Baseline. Run a normal load (50–70% of expected peak) and record p95 latency, error rate, CPU/memory.
2. Stepwise increase. Raise load by 10–20% every 2–5 minutes until errors or critical delay appear.
3. Find breaking point. Continue until error rate >5% or latency >5× baseline.
4. Recovery. Remove load and measure time to return to normal.

Below is a k6 scenario for a stress test with gradual ramp to 1600 virtual users:

// tests/stress/breaking-point.js
import http from 'k6/http'
import { check, sleep } from 'k6'
import { Rate, Trend, Counter } from 'k6/metrics'

const errorRate = new Rate('errors')
const requestsPerSecond = new Counter('requests_per_second')

export const options = {
  stages: [
    { duration: '2m',  target: 50 },
    { duration: '3m',  target: 50 },
    { duration: '2m',  target: 100 },
    { duration: '3m',  target: 100 },
    { duration: '2m',  target: 200 },
    { duration: '3m',  target: 200 },
    { duration: '2m',  target: 400 },
    { duration: '3m',  target: 400 },
    { duration: '2m',  target: 800 },
    { duration: '3m',  target: 800 },
    { duration: '2m',  target: 1600 },
    { duration: '3m',  target: 1600 },
    { duration: '5m',  target: 50 },
    { duration: '3m',  target: 0 },
  ],
  thresholds: {
    http_req_duration: [
      { threshold: 'p(95)<2000', abortOnFail: false },
    ],
    errors: [
      { threshold: 'rate<0.1', abortOnFail: false }
    ]
  }
}

const BASE_URL = __ENV.BASE_URL || 'http://localhost:3000'

export default function() {
  const responses = http.batch([
    ['GET', `${BASE_URL}/api/products?limit=20`],
    ['GET', `${BASE_URL}/api/categories`],
  ])

  responses.forEach(r => {
    check(r, { 'status 2xx': (r) => r.status >= 200 && r.status < 300 })
    errorRate.add(r.status >= 400)
  })

  requestsPerSecond.add(2)
  sleep(0.1)
}

export function handleSummary(data) {
  const stages = analyzeStages(data)
  return {
    'stress-results.json': JSON.stringify(data, null, 2),
    stdout: generateReport(stages)
  }
}

function generateReport(stages) {
  return `
=== STRESS TEST REPORT ===
Breaking Point Analysis:
${stages.map(s => `  VUs: ${s.vus} | p95: ${s.p95}ms | Errors: ${(s.errorRate*100).toFixed(1)}%`).join('\n')}
`
}

For a marketplace, the system was stable at 500 RPS but took 4 minutes to recover after load was removed. Diagnostics revealed misconfigured PostgreSQL connection pools. After optimization, recovery time dropped to 30 seconds and throughput increased to 1500 RPS.

Process and Estimation

Our work follows these steps:

1. Gather data – application architecture, expected traffic, endpoints to test.
2. Audit/Analysis – review infrastructure, identify likely bottlenecks.
3. Design test plan – define metrics, load profile, success criteria.
4. Estimate – provide time and cost based on complexity.
5. Execute stress test – run the scenario, collect metrics.
6. Deliver report – breaking point, recommendations, recovery time.
7. Retest – after fixes, validate improvements.

Typical projects start at $2,000 and can go up to $10,000 depending on complexity. Each project is evaluated individually.

Timelines

A standard stress test with the described scenario takes 2–3 business days. Complex architectures or multiple endpoints may require more time.

Common Mistakes & Checklist

• Ignoring recovery time. A system that survives load but recovers slowly may collapse under repeated spikes. Always measure recovery.
• Testing only happy path. Stress tests must include realistic user scenarios – searches, filters, checkouts.
• Not monitoring during test. Without parallel monitoring of CPU, memory, database connections, you cannot correlate symptoms with causes. We always run monitoring scripts.

#!/bin/bash
# scripts/monitor-stress-test.sh

TARGET_HOST="app-server-ip"
INTERVAL=10

while true; do
  TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)

  ssh $TARGET_HOST "
    echo -n '$TIMESTAMP '
    echo -n 'cpu:'; top -bn1 | grep 'Cpu(s)' | awk '{print \$2}'; echo -n ' '
    echo -n 'mem:'; free | grep Mem | awk '{print \$3/\$2 * 100}'; echo -n ' '
    echo -n 'load:'; cat /proc/loadavg | awk '{print \$1}'
    echo -n 'conns:'; ss -s | grep -o 'estab [0-9]*' | awk '{print \$2}'
  "

  ssh $TARGET_HOST "
    PGPASSWORD=pass psql -U app -d appdb -t -c \"
      SELECT 'active_queries:', count(*) FROM pg_stat_activity
        WHERE state = 'active' AND query NOT LIKE '%pg_stat%';
      SELECT 'long_queries:', count(*) FROM pg_stat_activity
        WHERE state = 'active' AND query_start < NOW() - interval '5 seconds';
      SELECT 'locks:', count(*) FROM pg_locks WHERE NOT granted;
    \"
  "

  sleep $INTERVAL
done | tee stress-monitor.log

Analyzing Results with Prometheus and Grafana

We stream k6 metrics to Prometheus via Remote Write and build dashboards in Grafana. Example PromQL:

# RPS in real time
rate(k6_http_reqs_total[30s])

# Error rate over time (find degradation moment)
rate(k6_http_req_failed_total[30s]) / rate(k6_http_reqs_total[30s])

# p95 latency in real time
histogram_quantile(0.95, rate(k6_http_req_duration_seconds_bucket[30s]))

Python script to automatically find the breaking point:

# analyze_stress_results.py
import json
import pandas as pd

def analyze_breaking_point(results_file):
    with open(results_file) as f:
        data = json.load(f)

    metrics = data['metrics']

    analysis = {
        'max_rps_before_errors': find_max_sustainable_rps(metrics),
        'error_threshold_rps': find_error_threshold(metrics),
        'latency_degradation_point': find_latency_degradation(metrics),
        'recovery_time_seconds': find_recovery_time(metrics),
    }

    print("=== Breaking Point Analysis ===")
    print(f"Max sustainable RPS (< 1% errors): {analysis['max_rps_before_errors']}")
    print(f"Error threshold RPS: {analysis['error_threshold_rps']}")
    print(f"p95 > 1s at RPS: {analysis['latency_degradation_point']}")
    print(f"Recovery time after load removal: {analysis['recovery_time_seconds']}s")

    if analysis['max_rps_before_errors'] < 100:
        print("\n[!] LOW capacity. Consider: DB connection pooling, caching, horizontal scaling")
    elif analysis['recovery_time_seconds'] > 120:
        print("\n[!] SLOW recovery. Consider: circuit breakers, graceful degradation")

    return analysis

What's Included in the Work

• Documentation of the breaking point (RPS, latency, error rate)
• Grafana dashboards with test history and metric correlation
• Prioritized optimization recommendations (critical / desirable)
• Retesting after changes are applied
• Recovery time report
• Guaranteed delivery within 2 business days

When to Stress Test?

We recommend stress tests after every major release, after architecture changes (e.g., migration to new hosting or adding caching), and quarterly to monitor performance degradation. This helps prevent downtime during peak loads.

Typical Bottlenecks and Diagnostics

Tool Comparison

k6 is 5x better than JMeter for stress testing in terms of resource efficiency and automation.

k6 wins in performance and automation simplicity. We use it on all projects. Our certified engineers have over 10 years of experience in load testing, allowing us to quickly identify bottlenecks and give precise recommendations.

Order a stress test and receive a detailed report with recommendations. We guarantee a comprehensive report within 2 business days. Or contact us to discuss your project.

Why are unit tests important but not a panacea?

A bug found by a unit test costs minutes to fix. The same bug in production costs hours of incident response, compensations, and lost trust. In an online store project, a discount calculation error passed manual testing, went to production, and processed 37 orders at zero price in 4 hours. An automated test for edge cases would have caught it on the first push. With 7+ years in web application testing and over 200 projects delivered, we’ve seen this pattern repeat across industries.

Jest is the standard for JavaScript/TypeScript, but unit tests are justified only where there is isolated logic: transformation functions, validators, business rules, utilities. Testing React components with Jest + Testing Library is correct for behavioral tests: "button appears after loading", "form shows error on empty email". Snapshot tests (toMatchSnapshot) are a trap: they break on any layout change and become noise that developers update without looking. Code coverage is a poor quality metric: 80% coverage can be achieved with tests that check nothing. Coverage shows that code executed, not that it works correctly.

Vitest as an alternative to Jest for Vite projects: 10–20x faster due to native ES modules without Babel transformation. For monorepos with thousands of tests, the speed difference is noticeable. Wikipedia on unit testing describes the theoretical foundation — we apply it with real CI pipelines.

How to set up E2E tests that are not flaky?

Playwright outperforms Cypress on key parameters: native multi-tab, multi-origin, iframe support; parallel execution at test level; WebKit, Firefox, Chromium out of the box; no iframe for the app — tests run in a real browser.

Playwright codegen records actions and generates a test — a good starting point, but generated code needs refactoring. Locators by text content are fragile: getByRole('button', { name: 'Place order' }) is more robust than locator('.btn-primary').

Page Object Model is the standard for organizing E2E tests. Each page is a separate class with methods instead of direct locators. When a button moves from header to sidebar — change in one place, not across all tests.

Flaky tests typically arise from race conditions between request and render, animations without wait, and dependency on external APIs. Solution: page.waitForResponse() instead of page.waitForTimeout(), mocking external APIs via page.route().

// Bad
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Good
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /order created/i })).toBeVisible();

Our engineers guarantee test stability in CI. Playwright’s official documentation covers all API details — we use it daily on projects with millions of users.

How do Core Web Vitals affect ranking?

Google uses Core Web Vitals in ranking. Lighthouse CLI in CI pipeline: on every deploy we check that LCP < 2.5s, CLS < 0.1, INP < 200ms. Google Chrome study: 53% of users leave a site if it takes longer than 3 seconds to load — our tests prevent such losses.

Real problems that Lighthouse finds:

• Hero image without width/height attributes: CLS 0.35 on load.
• JavaScript bundle 2.1MB synchronously blocking parsing: INP 450ms.
• Fonts without font-display: swap: invisible text until font loads (FOIT).
• Unoptimized hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) saves metric history and posts a comment to PR with degradation. For one e‑commerce client, optimizing these metrics improved conversion by 18% and reduced server costs by $12k annually.

What does load testing solve?

k6 is a load testing tool with a JavaScript API. Scenarios are written as code, versioned in git, run in CI. Three main scenarios:

• Spike test — sharp load increase: 0 → 1000 users in 30 seconds. Simulates a campaign launch. Shows system's ability to handle spikes.
• Soak test — stable load for 2–4 hours. Detects memory leaks, connection pool exhaustion, performance degradation.
• Stress test — load above expected (150–200% of peak). Shows breaking point and graceful degradation.

Thresholds:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms means 95% of requests respond faster than half a second. If threshold is not met, k6 exits with error code, CI pipeline fails.

In one online store project, we detected API degradation at the 4th hour of the test: p95 increased from 200ms to 2s due to connection leaks. After optimization, the client saved $15k per year on incident response and extra infrastructure.

Testing pyramid in a project

What does the work include?

• Audit of current coverage and identification of critical user flows.
• Writing unit tests for key business logic, integration tests for API, E2E for user scenarios.
• Setting up parallel execution in CI (sharded workers for Playwright).
• Load testing with report and recommendations.
• Test case documentation, training your team on test practices.
• 1-month warranty support after implementation.
• Delivery of all test artefacts (code, CI configs, run histories).

How do we work?

1. Analysis — audit of current testing, identification of weak spots, priority setting.
2. Design — tool selection, test plan writing, approval.
3. Implementation — writing tests, CI integration.
4. Testing — running all levels, result analysis, bug fixing.
5. Deployment — going live, metric monitoring, team training.

Timeline

Setting up a full test pipeline (Jest + Playwright + k6 + Lighthouse CI) from scratch: 2–4 weeks. E2E test coverage of an existing project (20–30 scenarios): 3–6 weeks. Load testing with report and recommendations: 1–2 weeks. Cost calculated individually after audit.

Ready to discuss your project? Leave a request — we will audit your current web application testing for free and propose a plan that can save up to 60% on incident costs. Get a consultation on web application testing — contact us today.