Scaling Performance: Building a Distributed Load Testing System with Locust on 3 Budget VPSs

Introduction to Cost-Effective Scale Testing

In today's digital landscape, application performance is a critical pillar of user retention and business success. A system that crashes under a sudden spike in traffic can result in lost revenue, brand damage, and frustrated stakeholders. However, simulating high-volume traffic to validate system resilience often comes with a hefty price tag, especially when relying on commercial cloud-based testing platforms.

For engineering teams operating under budget constraints, building an in-house performance testing infrastructure is a highly viable alternative. This technical guide demonstrates how to architect, configure, and execute a Distributed Load Testing system using Locust across three budget Virtual Private Servers (VPS). By leveraging open-source software and affordable infrastructure, you can simulate thousands of concurrent users efficiently and affordably.

Why Locust and Budget VPS?

Traditional load testing tools like Apache JMeter are powerful but can be highly resource-intensive due to their thread-based concurrency model. Locust, on the other hand, utilizes an asynchronous, event-driven architecture powered by gevent. This allows a single Locust process to handle thousands of concurrent users (or "User greenlets") on modest hardware, making it the ideal candidate for a budget-friendly setup.

By spreading the load across three distinct VPS instances, we achieve several distinct advantages:

Risk Mitigation: Preventing the testing tool itself from becoming the performance bottleneck due to CPU or memory saturation on a single machine.
Network Realism: Generating traffic from multiple IP addresses to better simulate realistic network distribution and bypass single-IP rate limits.
Cost Efficiency: Utilizing entry-level VPS instances (e.g., 1 vCPU, 2GB RAM) rather than high-tier, expensive cloud instances.

Architectural Blueprint: Master-Worker Topology

To successfully distribute our load, we establish a classic master-worker topology across our three VPS instances. In this design, roles are strictly segregated to optimize resource consumption:

The Master Node (VPS 1): This instance acts as the orchestrator. It hosts the web user interface (UI), collects real-time metrics from the workers, and aggregates performance data. Crucially, the master node does not generate any test traffic itself, ensuring its resources are preserved for system coordination and reporting.

The Worker Nodes (VPS 2 and VPS 3): These instances run the actual test scripts. They receive instructions from the master node, execute the user simulation logic, and continuously stream performance metrics back to the master.

Step-by-Step Deployment Guide

Step 1: Preparing the Infrastructure and System Limits

Before installing Locust, you must prepare all three VPS instances (assuming Ubuntu 24.04 LTS). Because load testing opens thousands of concurrent network connections, default operating system limits will quickly cause "Too many open files" errors. Run the following commands on all three nodes to increase the system limits:

sudo bash -c 'cat <> /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535
EOF'

Apply the changes by running sudo sysctl -p or logging out and back in. Next, install Python 3 and the required dependencies across all machines:

sudo apt update && sudo apt install -y python3-pip python3-venv libev-dev
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install locust

Step 2: Writing the Simulation Script (locustfile.py)

Create a file named locustfile.py. This file must be identical on both Worker nodes, as they execute the logic locally. Here is a robust script simulating standard user behavior on an e-commerce platform:

from locust import HttpUser, task, between, SequentialTaskSet

class UserBehavior(SequentialTaskSet):
    @task
    def view_homepage(self):
        self.client.get("/")

    @task
    def browse_products(self):
        self.client.get("/products", name="/products")

    @task
    def view_cart(self):
        self.client.get("/cart", name="/cart")

class ECommerceSimulation(HttpUser):
    wait_time = between(1, 5)
    tasks = [UserBehavior]

Step 3: Launching the Master Node

On VPS 1 (Master), start the Locust process in master mode. Ensure your firewall allows incoming traffic on port 8089 (Web UI) and port 5557 (Worker communication):

locust -f locustfile.py --master

Keep this terminal running or manage it via systemd/tmux. The master will output that it is successfully listening for workers.

Step 4: Launching the Worker Nodes

On VPS 2 and VPS 3 (Workers), initiate the worker processes by pointing them to the private or public IP address of the Master node (replace with VPS 1's IP):

locust -f locustfile.py --worker --master-host=

Upon successful initialization, your Master node terminal will update to display: The master node has connected 2 workers.

Executing the Test and Analyzing Metrics

With the cluster operational, open your web browser and navigate to http://:8089. You will be greeted by the Locust web interface. Here, specify the total number of users to simulate, the spawn rate (users added per second), and the target host URL.

As the test runs, monitor the following three pillars of performance metrics:

Median and 95th Percentile Response Time: Look for stable plateaus. Spikes in the 95th percentile indicate that while average users might experience speed, a subset of your user base is facing severe lag.
Failures/s vs Request/s: If the failure rate rises in tandem with the request rate, your target application server is likely hitting a resource ceiling (CPU, database connection pool, etc.).
Worker Status: Ensure neither VPS 2 nor VPS 3 exceeds 85% CPU utilization. If a worker saturates its own CPU, it can no longer generate accurate requests, skewing your results.

Best Practices for Distributed Load Testing

To maximize the efficacy of your cost-effective cluster, adhere to these production guidelines:

Run Headless for Max Performance: For heavy load tests, bypass the Web UI overhead entirely by running the master in headless mode via CLI arguments, exporting results directly to CSV or Grafana.
Mind the Network Costs: Budget VPS providers often provide generous, but limited, monthly bandwidth. High-throughput tests can consume hundreds of gigabytes quickly; monitor your data usage closely.
Time Synchronization: Ensure all three VPS clocks are precisely synchronized using NTP (Network Time Protocol) to prevent anomalies in time-series data aggregation.

Conclusion

Building a distributed load testing system does not require premium enterprise budgets. By combining the asynchronous efficiency of Locust with strategic system configuration across three affordable VPS instances, development teams can gain deep insights into application limits. This architecture provides a scalable, repeatable framework ensuring your applications remain highly performant and stable under pressure.