LoadStrike
Start Free Trial
Java load testing

Java load testing for service workflows

Published 2026-10-03 | Updated 2026-10-03 | LoadStrike Documentation Team

Use the LoadStrike Java SDK for load and performance testing on Java 17+. Connect HTTP steps, client calls and downstream completion in one run.

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

How do you write a Java load test with LoadStrike?

LoadStrike supports Java load testing through the com.loadstrike:loadstrike SDK on Java 17+. Engineers write scenarios and named steps around their clients, select a load profile and inspect the run report. A request-step test establishes HTTP behavior; transaction correlation adds the downstream event that proves the service workflow completed.

Start with a small test

Install and start an API load test in Java

The Java request-step example includes imports and method-body statements. Put those statements inside a class method or main method. The linked Java sample project supplies Maven and source context; replace the example target and placeholder runner key.

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

Add this dependency to pom.xml and place the import in your Java source. Version 1.0.33301 is a published Maven Central release verified on 3 October 2026; check Maven Central when choosing a later release.

<dependency>
  <groupId>com.loadstrike</groupId>
  <artifactId>loadstrike</artifactId>
  <version>1.0.33301</version>
</dependency>

import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeRunner;

Request-step example

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeResponse;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeRunner;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeScenario;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeSimulation;
import com.loadstrike.runtime.LoadStrikeRuntime.LoadStrikeStep;

var client = HttpClient.newHttpClient();

var scenario = LoadStrikeScenario
    .create("read-order", context -> LoadStrikeStep.run("GET /orders/{id}", context, () -> {
      String orderId = "ord-" + context.invocationNumber;
      var request = HttpRequest.newBuilder(URI.create("https://api.example.com/orders/" + orderId))
          .GET()
          .build();
      var response = client.sendAsync(request, HttpResponse.BodyHandlers.ofString()).join();
      return response.statusCode() < 400
          ? LoadStrikeResponse.ok(Integer.toString(response.statusCode()))
          : LoadStrikeResponse.fail(Integer.toString(response.statusCode()), "Order lookup failed");
    }).asReply())
    .withLoadSimulations(LoadStrikeSimulation.inject(10, 1d, 20d));

LoadStrikeRunner
    .registerScenarios(scenario)
    .withRunnerKey("rkl_your_local_runner_key")
    .run();
Proof

Evidence to review

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

Java sample project

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

Who this is for

Java backend teams who want performance scenarios in the same language as their services and clients. This is useful when authentication, message data or generated client behavior must remain explicit in code, rather than being hidden in a recording or reconstructed after a run.

Package, runtime and client setup

Add com.loadstrike:loadstrike to your Maven project with a concrete published release version from Maven Central. The SDK runtime types are imported from com.loadstrike.runtime.LoadStrikeRuntime. The introductory example uses the JDK HttpClient. Its executable statements belong inside a class method or main method; the public Java project provides the surrounding build and import context.

From request timing to completion

For HTTP-to-event workflows, define the source action, observable completion endpoint, shared tracking value and correlation timeout. gRPC endpoints use customer-provided Produce or Consume delegates; native gRPC execution is unavailable. Your generated Java gRPC client owns the call, deadlines and authentication, then returns the result used by LoadStrike correlation.

Execution and plan requirements

  • Use Maven artifact com.loadstrike:loadstrike on Java 17+ 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

  • Retain JMeter plans that already answer a release question. Add one Java scenario beside the existing suite, use comparable data and completion criteria, and assess report usefulness and maintenance effort before expanding adoption.
  • Check transport-specific limits before selecting a workload. For native Java WebSocket reads, each fully reassembled inbound text or binary message is limited to 1 MiB. Browser tests also require the separate client package and browser or driver setup.
Common questions

Common questions

Is the Java quick start a complete Java source file?

It is a request-step snippet. Put the statements in a class method or main method and use the public Java sample project for Maven configuration and imports before running your own target.

Does Java gRPC testing use a built-in native client?

No. Configure the matching Produce or Consume delegate around your generated gRPC client. Native execution is unavailable, and the gRPC endpoint requires Pro or Enterprise access.

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.

gRPC Protocol Guide

Use this guide when gRPC services are part of the workflow and you need unary or streaming calls to participate in the same LoadStrike tracking and reporting model.

WebSocket Protocol Guide

Use this guide when long-lived WebSocket sessions, message matching, or realtime channels need to be part of a performance or transaction test.

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 Java performance scenario

Start one Java performance scenario

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

Open the quick start Review plan coverage