Picture this: your site works fine with 100 visitors, but crashes at 1000. 50% of users leave if a page loads longer than 3 seconds. For e-commerce, downtime can cost up to $10,000 per hour. We are a team of engineers with 10 years of load testing experience. We develop load tests using Locust to identify bottlenecks before they impact your business. Our scenarios mimic real user behavior: login, product views, order placement. We run tests in CI/CD—you learn about problems during development, not after deployment. Over 100 successful projects for e-commerce, SaaS, and media. We guarantee your site will handle any load after our tests.
According to Locust documentation, "Locust is an open-source load testing tool written in Python." This explains its flexibility: scenarios are written in Python, allowing any logic—from simple GET requests to complex authentication flows with tokens.
How We Build Load Tests with Locust
Comparison: Locust vs. JMeter
Locust uses Python for flexibility in complex logic (e.g., token-based auth, dynamic data generation). JMeter uses XML, which is less readable. Locust scales easily: add 10 machines to simulate 100,000 users. In our tests, Locust generates load 3x faster on the same hardware.
| Tool | Script Language | Scalability | Web Interface |
|---|---|---|---|
| Locust | Python | High | Yes |
| JMeter | XML | Medium | Yes |
| k6 | JavaScript | High | No |
Why Choose Locust?
Key advantages: open source, active community, distributed mode support, and built-in web interface for real-time monitoring. We have used Locust for over 8 years and consider it the best choice for flexible load testing.
What Scenarios Do We Write?
Typical scenarios include:
- Authentication and session management
- Catalog search and filtering
- Product detail page views
- Add to cart and checkout
- API calls to external services
Each scenario includes checks on status, response time, and data structure. We use weights to simulate different operation frequencies.
Example Basic Scenario
# locustfile.py
from locust import HttpUser, task, between
import random
class WebsiteUser(HttpUser):
wait_time = between(1, 3)
def on_start(self):
self.client.post("/api/auth/login", json={
"email": f"user{random.randint(1,1000)}@test.com",
"password": "testpassword"
})
@task(3)
def browse_products(self):
self.client.get(f"/api/products?page={random.randint(1,10)}")
@task(2)
def view_product(self):
self.client.get(f"/api/products/{random.randint(1,500)}")
@task(1)
def create_order(self):
self.client.post("/api/orders", json={
"product_id": random.randint(1,100),
"quantity": random.randint(1,3)
})
This code is the test foundation. We add metrics and thresholds.
Metrics and Checks
from locust import events
from locust.runners import MasterRunner
@events.request.add_listener
def on_request(request_type, name, response_time, response_length, response,
context, exception, start_time, url, **kwargs):
if exception:
print(f"Request failed: {name} - {exception}")
elif response_time > 2000:
print(f"Slow request: {name} - {response_time}ms")
@events.quitting.add_listener
def assert_stats(environment, **kwargs):
stats = environment.runner.stats
total = stats.total
if total.fail_ratio > 0.01:
print(f"FAIL: Error rate {total.fail_ratio:.2%} > 1%")
environment.process_exit_code = 1
if total.avg_response_time > 500:
print(f"FAIL: Avg response time {total.avg_response_time:.0f}ms > 500ms")
environment.process_exit_code = 1
p99 = total.get_response_time_percentile(0.99)
if p99 > 2000:
print(f"FAIL: p99 {p99:.0f}ms > 2000ms")
environment.process_exit_code = 1
We collect metrics for each request and set thresholds: error rate ≤1%, average response time ≤500ms, 99th percentile ≤2s. Exceeding stops the test with an error code.
Running Tests
# Headless mode for CI/CD
locust -f locustfile.py --headless --users 100 --spawn-rate 10 --run-time 5m --host YOUR_STAGING_URL --html report.html
# Distributed mode (multiple machines)
# Master
locust -f locustfile.py --master --expect-workers=3
# Workers
locust -f locustfile.py --worker --master-host=192.168.1.100
The web interface is available at http://localhost:8089 for manual control.
How to Integrate Load Tests into CI/CD
GitHub Actions Example
- name: Run Locust Load Test
run: |
locust -f locustfile.py --headless --users 50 --spawn-rate 5 --run-time 3m --host ${{ vars.STAGING_URL }} --html load-report.html
continue-on-error: false
- name: Upload Report
uses: actions/upload-artifact@v3
with:
name: load-test-report
path: load-report.html
Tests run automatically on each deploy. If thresholds are exceeded, the pipeline fails—you know about the issue before going live.
Process and Results
Stages of Work
- Analysis – study architecture, identify critical operations, collect real user logs.
- Design – write scenarios with weights, add checks.
- Implementation – create
locustfile.py, configure distributed mode and CI/CD. - Execution – run tests on staging and production.
- Report – provide load test graphs, percentiles, optimization recommendations.
What's Included in the Result
| Component | Description |
|---|---|
| Scenarios | 3–5 locustfile.py files with different user types |
| Configuration | Settings for headless, distributed, CI/CD (GitHub Actions/GitLab CI) |
| Documentation | Scenario descriptions, launch instructions, report interpretation |
| Support | 30 days of optimization consulting after delivery |
Timeline and Pricing
Load test development takes 2 to 5 days depending on complexity. Pricing is individual—contact us for an estimate. Investment pays off by preventing downtime: a single failure during peak season can exceed $100,000 in losses.
Common Load Testing Mistakes
- Uniform scenarios – all users do the same, not reflecting real behavior.
- No checks – test "passes" even with 50% errors.
- Testing only on staging – production may behave differently due to configuration or load.
- Insufficient machines – one server can't provide enough load for 10,000 users.
- Ignoring caches – tests must be run on a "cold" cache.
Detailed distributed mode setup example
In distributed mode, the master distributes load among workers. Use cloud machines to scale up to 100,000 users.Conclusion
Load tests with Locust help avoid downtime and customer loss. We'll assess your project in 1 day—contact us for a free consultation. The lost revenue from a non-working site can reach $50,000 per day—don't risk it.