Python load testing

Python load testing for APIs and event workflows

Write Python load and performance tests with LoadStrike. Start with HTTP, add optional broker clients and measure correlated workflow completion.

LoadStrike documentation map for Python scenarios, runtime configuration and reports
Write Python performance scenarios, verify SDK requirements and measure request or downstream completion evidence.

How do you write a Python load test with LoadStrike?

LoadStrike lets Python teams express API load tests and transaction performance tests as Python scenarios. Named steps make operations visible in the report, and load simulations define the workload. The starting example uses requests for HTTP; optional broker clients let a later scenario include the event or queue that confirms completion.

Start with a small test

Install and start an API load test in Python

The Python request-step snippet imports requests as well as loadstrike_sdk. Install both with pip install LoadStrike requests, replace the example API and placeholder runner key, and keep the HTTP timeout appropriate for your target.

The request-step example offers 10 scenario invocations per second for 20 seconds. Replace the example endpoint with an authorized staging service and the placeholder with your valid runner key. Offered scenario invocations are not measured HTTP throughput or a benchmark result.

SDK installation

The base install contains the core SDK. Add one of `kafka`, `rabbitmq`, `nats`, `redis`, `eventhubs`, `sqs`, or `websocket` for that native client. `all-transports` installs all six broker clients plus WebSocket, while Prometheus Remote Write and CloudWatch need the separate `reporting` extra. Use `pip install "loadstrike[all-transports,reporting]"` when both sets are required.

pip install LoadStrike
pip install "loadstrike[kafka]"
pip install "loadstrike[rabbitmq]"
pip install "loadstrike[nats]"
pip install "loadstrike[redis]"
pip install "loadstrike[eventhubs]"
pip install "loadstrike[sqs]"
pip install "loadstrike[websocket]"
pip install "loadstrike[reporting]"
pip install "loadstrike[all-transports]"

from loadstrike_sdk import LoadStrikeRunner

Request-step example

import requests

from loadstrike_sdk import (
    LoadStrikeResponse,
    LoadStrikeRunner,
    LoadStrikeScenario,
    LoadStrikeSimulation,
    LoadStrikeStep,
)

def read_order(context):
    def run_step():
        order_id = f"ord-{context.invocation_number}"
        response = requests.get(f"https://api.example.com/orders/{order_id}", timeout=15)
        if response.ok:
            return LoadStrikeResponse.ok(str(response.status_code))
        return LoadStrikeResponse.fail(str(response.status_code), "Order lookup failed")

    return LoadStrikeStep.run("GET /orders/{id}", context, run_step).as_reply()

scenario = (
    LoadStrikeScenario.create("read-order", read_order)
    .with_load_simulations(LoadStrikeSimulation.inject(10, 1, 20))
)

LoadStrikeRunner.register_scenarios(scenario) \
    .with_runner_key("rkl_your_local_runner_key") \
    .run()
Proof

Evidence to review

Use these pages and artifacts to validate the public claims on this page.

Python sample project

Inspect the project configuration, imports and source examples. Dummy runner keys must be replaced.

Who this is for

Python service developers and QA engineers who want test data, clients and assertions reviewed in Python. Choose this SDK when maintaining a Python test project makes the workload easier for the owning team to understand; the language alone does not guarantee generator throughput.

Package, runtime and client setup

Install the core PyPI package with pip install LoadStrike on Python 3.9.2+ and import runtime types from loadstrike_sdk. The HTTP quick start also imports requests, which is a separate dependency: install it in your test environment. Use an isolated environment and record dependency versions so a later run uses comparable client behavior.

From request timing to completion

Install the matching optional extra for native Kafka, RabbitMQ, NATS, Redis Streams, Azure Event Hubs, AWS SQS or WebSocket clients. The all-transports extra includes those six broker clients plus WebSocket; Prometheus Remote Write and CloudWatch require the separate reporting extra. For completion testing, preserve a shared tracking value between source and destination and configure the timeout and endpoint modes.

Execution and plan requirements

  • Use PyPI package LoadStrike on Python 3.9.2+ and provide a valid runner key. LoadStrike runs on your own infrastructure.
  • Check the plan for the selected endpoints, reports and execution mode. gRPC and WebSocket endpoints require Pro or Enterprise; extra clients do not grant plan access.
  • Review HTML, CSV, TXT or Markdown reports and run failures. These examples demonstrate SDK setup; they are not comparative benchmarks or throughput guarantees.

Define the workload and inspect the evidence

Start with a small request-step test against a staging system you control. To measure later completion, define the matching endpoints and tracking value before interpreting transaction latency.

Introduce the workload into your test project

  • Keep Python unit and functional tests for their original assertions. Add one small staging workload, inspect response failures and report artifacts, then choose a realistic arrival or concurrency profile rather than assuming a larger rate is a better test.
  • Reuse a trusted browser flow only after installing its Playwright or Selenium dependency and required browser binaries or driver. gRPC calls require a customer-provided delegate and generated client; native gRPC execution is unavailable.
Common questions

Common questions

Does installing LoadStrike also install requests?

No. The documented HTTP example uses requests as the chosen client. Install it separately, or implement the HTTP operation with a client already available in your project.

Does all-transports include every reporting client?

No. all-transports supplies the optional broker and WebSocket clients. Install the reporting extra separately when the test uses Prometheus Remote Write or CloudWatch; confirm plan entitlements as well.

Related

Related documentation

Start with the implementation details that match this page.

Installation

Install the LoadStrike package for your language and add it to the test project you already use. This page is the starting point before you write a scenario.

Quick Start

Build one basic request-step scenario around GET /orders/{id}, run it, and confirm the report before moving into correlation-specific features.

Load Simulation

Load simulations describe how traffic should arrive over time. Use them to model the shape of the workload instead of only its peak.

Kafka Endpoint

Configure Kafka load and performance testing with LoadStrike: publish and consume records, preserve tracking IDs, and observe downstream completion.

Expanded Built-In Sinks

Use the expanded sink set when LoadStrike run data should flow into supported observability platforms, databases, message streams, StatsD collectors, JSONL files, or a generic webhook receiver.

Related

Related comparisons

Use these comparison pages if you still need a tool-level decision.

LoadStrike vs k6

Compare LoadStrike and k6 for APIs, Kafka, browser tests and async completion, including correlation requirements, extensions and hosting tradeoffs.

LoadStrike vs Apache JMeter

Compare LoadStrike and Apache JMeter for async completion, JMS, browser execution, reports and self-hosted testing, including setup and licensing requirements.

Next steps

Start one Python performance scenario

Start one Python performance scenario

Install the SDK, provide a valid runner key and review one small staging run before increasing load or adding downstream correlation.