Skip to main content

Load Testing Guide

Load testing is essential to ensure your application can handle production-level traffic and to identify performance bottlenecks in your specific business logic.

The native benchmarking toolchain in Framework M is powered by Locust via the m benchmark CLI command. This enables configuration-driven load testing using simple YAML templates.

2. Testing the Meta-API​

Since Framework M provides a standard Meta-API for all DocTypes, you can use generic load testing scripts to test CRUD performance.

2.1 Studio Harness​

Framework M Studio provides a built-in m benchmark command that discovers DocTypes, handles auth, and generates payloads. See the Load Testing Harness and Load Testing Reference docs for the full config schema.

2.2 Locust Boilerplate​

For custom scenarios, create a locustfile.py to test a specific DocType (e.g., Item).

from locust import HttpUser, task, between


class FrameworkMUser(HttpUser):
    wait_time = between(1, 2)

    def on_start(self):
        # Authenticate if necessary
        self.client.headers.update({"Authorization": "Bearer sample-token"})

    @task(3)
    def list_items(self):
        """Test listing documents."""
        self.client.get("/api/v1/Item?limit=10")

    @task(1)
    def create_item(self):
        """Test creating a document."""
        self.client.post(
            "/api/v1/Item", json={"name": "Test Item", "description": "Load test data"}
        )

3. Interpreting Results​

Readiness Probe and Load​

During extreme load, the database or background queue might become saturated. Monitor the /ready endpoint during your tests.

  • 503 (Readiness): If /ready starts returning 503 while under load, the pod is effectively telling Kubernetes to stop sending it more traffic. This is a sign of resource exhaustion.

Key Metrics to Monitor​

  1. Response Time (p95/p99): Aim for < 200ms for standard CRUD operations.
  2. Error Rate: Should remain < 1% under peak load.
  3. Database CPU/IO: Identify if the bottleneck is in the database adapter or the Python runtime.

4. Production Load Simulation​

To get the most accurate results:

  1. Use Production-like Hardware: Test in a staging environment that mirrors production specs.
  2. Seed Data: Ensure the database has at least 50% of the expected production volume (e.g., 100k+ records) to test index performance.
  3. Test Concurrent Jobs: Trigger background jobs (Event Bus) while the API is under load to see the impact on responsiveness.