Turnkey Load Testing for Websites with Apache JMeter

Your website may slow down starting from 500 concurrent visitors. During peak load (a sale, a campaign launch), the server times out and users see a 503 error. Without load testing, you cannot guarantee stable production performance. We are engineers who know how to simulate real-world load with Apache JMeter and identify weak spots before your customers notice them. Over the years, we have performed load testing for 30+ projects — from e-commerce stores to SaaS platforms. Each project has a unique stack and architecture, so we never use cookie-cutter solutions. Savings from early detection of issues can amount to 500,000 rubles per hour of critical service downtime.

How We Develop Load Tests with Apache JMeter

We start by analyzing the architecture: which endpoints are the heaviest, what scenarios users execute (registration, search, add to cart, checkout). We study the database structure, profile queries, and identify critical paths. For each scenario, we create a Thread Group with parameters: number of virtual users (up to 10,000), ramp-up time, and test duration.

Example test plan for an e-commerce site:

Test Plan
├── Thread Group (1000 users, ramp-up 60 s, duration 300 s)
│   ├── HTTP Request Defaults (domain, port, protocol)
│   ├── HTTP Cookie Manager
│   ├── CSV Data Set Config (users.csv: email,password)
│   ├── Login Sampler (POST /api/auth/login)
│   ├── JSR223 PostProcessor (extract JWT)
│   ├── Think Time (Uniform Random Timer 1000-3000 ms)
│   ├── Products Sampler (GET /api/products)
│   └── JSON Assertion (check response)
├── Backend Listener (InfluxDB)
└── View Results Tree (for debugging)

We parameterize data using CSV Data Set Config — this ensures unique credentials without conflicts.

Step 1: Define Test Objectives

We clearly specify what we are testing: maximum throughput, response time under load, or behavior during component failures. This determines the scenarios.

Step 2: Create Scenarios

For each user path, we write a sequence of requests with realistic timings. We use JSR223 PreProcessor to generate dynamic data (tokens, product IDs).

Step 3: Configure Assertions

We add response checks: HTTP status code, JSON schema, regular expressions. Without these, the test will miss hidden errors.

Step 4: Execute and Monitor

We run the test in CLI mode and collect metrics via Backend Listener to InfluxDB. In Grafana, we display a real-time dashboard.

Step 5: Analyze Results

After completion, we generate an HTML report with aggregated data. We pinpoint bottlenecks and provide optimization recommendations.

Which Metrics Do We Analyze?

We measure key performance indicators:

• Throughput (RPS) — requests per second the server can handle.
• Response Time (p50, p95, p99) — median, 95th, and 99th percentiles. If p99 exceeds 1000 ms, it's a problem.
• Error Rate — HTTP 4xx/5xx, timeouts.
• Resource Utilization — CPU, RAM, disk I/O (collected via server metrics).
• Core Web Vitals — LCP, TTFB, CLS.

All metrics are collected in real-time and visualized in Grafana. We also configure alerts: if response time exceeds a threshold, the team is notified. This allows quick reaction to issues. For example, on one project we observed that at 2000 RPS, API response time jumped from 200 ms to 3 s — the cause was an N+1 query to the database. After optimizing queries with JOINs and caching, response time returned to normal.

Why Choose Us for Load Testing?

We don't just run JMeter 'out of the box'. Our engineers are certified in Apache JMeter (Advanced level) and experienced with distributed testing on clusters of up to 10 nodes. Distributed JMeter scales better than Locust or k6 by a factor of 2 under loads above 1000 RPS — this is proven in practice. Unlike abstract estimation, we provide concrete graphs and numbers integrated with your monitoring system. We guarantee all scenarios are repeatable and can be run in CI/CD (Jenkins, GitLab CI).

"JMeter is designed to load test functional behavior and measure performance." — Apache JMeter Documentation

Comparison of JMeter run modes:

For most production loads, we recommend distributed mode — it scales linearly.

Comparison of load testing tools:

JMeter wins on max load and configuration flexibility, especially for distributed testing.

What's Included in the Work?

• Development of a test plan (JMX) with 5–7 load scenarios, including Thread Groups, timers, assertions, and listeners.
• Parameterization via CSV files and environment variables for repeatability.
• Configuration of Backend Listener to send metrics to InfluxDB.
• Creation of a Grafana dashboard with key graphs.
• HTML report with bottleneck analysis and recommendations.
• Consultation on results and assistance with optimization.

Load testing cost is calculated individually based on scenario complexity and required configuration. Get a consultation on load testing for your project.

How to Configure the Load Scenario Correctly?

Proper configuration includes choosing appropriate parameters: the number of users should match expected peak load, ramp-up time at least 30 seconds for smooth growth, test duration at least 5 minutes for stabilization. It is also important to realistically emulate think time between user actions.

Timeline

Development of a JMeter test plan with 5–7 load scenarios: 3 to 6 days. If distributed testing or CI/CD integration is needed, the timeline extends to 8–10 days.

Contact us to discuss your project and get a preliminary load testing plan. Order testing and be confident in your website's performance.

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.