Load Test in Mobile Development — What It Is, Scenarios, and How It’s Conducted

What is Load Test?

Load Test is a process of verifying how a system performs under an expected number of concurrent requests or users. In the context of mobile development, Load Test is applied to both the server-side (API, database, cache) and the client-side (push notification processing, data synchronization). The main difference from stress testing is that Load Test simulates real, not extreme, load. According to the AWS Well-Architected Framework (2024), load testing should be conducted using load profiles based on real usage analytics.

Load Test can be performed at the level of HTTP requests to the API, WebSocket connections, or database transactions. The goal is to ensure that the response time of each request does not exceed a specified threshold (typically 500–1000 ms for API), and throughput (RPS — requests per second) meets the requirements. Google Cloud Armor (2024) defines threshold values based on percentiles: p95 response time should not exceed 2 seconds for critical endpoints.

Load testing of a mobile backend includes simulating typical scenarios: registration, authorization, feed loading, form submission. Scenarios are recorded as HAR files (HTTP Archive) and replayed by the load testing tool. According to k6 documentation (2025), HAR conversion can reduce Load Test preparation time by 60%.

Goals of Load Testing

The first goal of Load Test is confirming system throughput. If the specification requires handling 1000 RPS, the load test must confirm this with a 20% buffer. According to the Netflix Tech Blog (2024), load testing at Netflix is conducted with a 2x buffer from peak load: if 10000 RPS is expected, the test checks 20000 RPS. This approach guarantees stability during sudden traffic spikes.

The second goal is identifying bottlenecks in the architecture. Typical bottlenecks in mobile backends are the database (slow queries), cache (incorrect invalidation strategy), and external APIs (slow third-party services). Distributed tracing (Jaeger, Zipkin) helps localize the problem at the level of a specific service or request.

The third goal is determining the saturation point. This is the moment when adding new users no longer increases throughput. In mobile applications, the saturation point often occurs at 70–80% CPU load on database servers. Auto-scaling should trigger before reaching this point.

Load Test Scenarios

Spike Test — simulates a sharp burst of activity, such as a morning push notification blast or a marketing campaign launch. According to Grafana k6 (2025), Spike Test simulates load growth from 100 to 10000 RPS in 30 seconds. The system must handle this without losing requests and without exceeding response time by more than 50%.

Endurance Test — checks system stability during prolonged operation under load. Typical duration is 1–4 hours. Endurance Test reveals memory leaks in server applications, database connection pool issues, and cache performance degradation. PostgreSQL connection pool under prolonged load without proper configuration can exhaust available connections within 2–3 hours of operation.

Step Load Test — gradual load increase with a step of 10–20% every 2–5 minutes. This scenario helps find the exact boundary after which the system degrades. InfluxDB and Prometheus collect metrics at each step to build a response time vs RPS graph.

Load Test Metrics

Response Time

Response Time is the primary Load Test metric. Measured in milliseconds and analyzed by percentiles: p50 (median), p95, and p99. Google SRE (2024) recommends a p95 threshold of no more than 1000 ms for REST API and no more than 200 ms for gRPC. Percentiles are more important than averages because they show the behavior of the worst requests, which users notice first. Apdex (Application Performance Index) is a composite metric that considers the proportion of satisfied, tolerating, and frustrated users.

Throughput

Throughput — the number of successful requests per unit of time. Measured in RPS (requests per second) or TPS (transactions per second). The Throughput graph in “time — RPS” coordinates should be linear until the saturation point. A sharp drop in Throughput with increased load is a sign of reaching the system’s limit. Apache Bench and wrk are simple CLI tools for quick Throughput checks during development.

Error Rate

Error Rate — the proportion of responses with HTTP status 4xx or 5xx out of total requests. The acceptable threshold is less than 1%. Errors 429 (Too Many Requests) and 503 (Service Unavailable) under high load indicate the need to configure rate limiting and auto-scaling. A rate limiter on the API Gateway side protects the backend from exceeding the allowed load. Retry policy with exponential backoff helps clients correctly handle temporary errors.

Tools for Load Test

k6 (Grafana)

k6 — the leading Open Source load testing tool from Grafana. Scripts are written in JavaScript, supporting modular scenarios, thresholds, and integration with Prometheus and InfluxDB. k6 can run both in CLI and in the Grafana Cloud k6 cloud. Grafana Cloud automatically builds dashboards from Load Test results and compares them with historical data. k6 supports Protocol Buffers and gRPC via a separate k6/net/grpc module.

Apache JMeter

Apache JMeter — a classic Load Test tool with a graphical interface. Supports a wide range of protocols: HTTP, JDBC, JMS, FTP, and TCP. JMeter is better suited for complex scenarios with many different types of requests but requires more manual configuration compared to k6. JMeter Plugins extend functionality for WebSocket and gRPC testing. For distributed execution, JMeter uses a master-slave architecture with one controller.

Locust

Locust — a Python-based tool that allows describing load scenarios in code. Locust is convenient for teams that use Python as their primary automation language. Unlike k6 and JMeter, Locust supports distributed execution out of the box: one master node coordinates several worker nodes. Distributed execution allows generating load up to 100000 RPS from multiple machines. Locust also supports WebSocket testing through custom extensions.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Example of Writing a Load Test in k6

The k6 script shown above demonstrates a typical load test structure. Options define the load profile: ramp-up for 2 minutes to 100 users, then 5 minutes of constant load, and another ramp-up to 200 users. Thresholds define test pass criteria: p95 request time no more than 500 ms, error rate less than 1%. If thresholds are exceeded, k6 exits with a non-zero code — this allows integrating Load Test into CI/CD.

In mobile development, Load Test of the server-side is especially important when launching new features that create additional load: likes, comments, streaming. Recommendation — conduct a Load Test on every staging before deploying to production. Creating a baseline load profile during the API design phase helps avoid architectural problems in later stages.