Using Bytecode Enhancement in Full-Chain Load Testing Scenarios

Load testing is essential for evaluating system capacity and stability under extreme load. Traditional offline load testing faces challenges in microservice architectures due to complex call chains, high cost of replica machines, and difficulty identifying bottlenecks.

Therefore, full‑chain load testing in the production environment is necessary. It requires a platform that can record and replay traffic, and SDKs for each language stack to propagate test markers and intercept/forward traffic for databases, MQ, etc.

This article focuses on adapting full‑chain load testing to the Java stack and the implementation of the Sftc‑Agent.

Technical choices

Two implementation options exist for Java: fork an existing open‑source SDK and modify its source, or use a Java Agent to perform runtime bytecode manipulation. A comparison table shows that component modification offers good readability but is invasive and hard to upgrade, whereas bytecode enhancement is non‑intrusive, easier to upgrade, but more difficult to develop.

Based on these considerations, bytecode enhancement was selected.

Bytecode tool selection

Four bytecode libraries were evaluated: ASM, ByteBuddy, Javassist, and a generic bytecode library. Their characteristics and drawbacks were compared. ByteBuddy was chosen for its friendly API and acceptable performance.

Java Agent usage

Java Agent can be used statically by adding -javaagent:sftc-agent.jar to the JVM startup command, which invokes the premain method, registers a transformer, and then runs the application’s main method, allowing bytecode modification during class loading.

Alternatively, a dynamic attach approach can load the agent into a running JVM via its PID.

Sftc‑Agent implementation

Sftc‑Agent is an internal Java Agent library that provides transparent, non‑intrusive full‑chain load testing. It consists of several modules loaded by custom class loaders to isolate them from the application class loader:

Agent – entry point that loads other modules and registers bytecode callbacks.

Bootstrap‑Inject – modules that need to be added to the bootstrap class loader (e.g., HttpURLConnection enhancements).

Common – shared utilities.

Plugin – concrete enhancements for Redis, Kafka, etc.

Plugin‑Api – shared classes for plugins.

Agent‑Core – core functions such as hot configuration and logging.

Custom class loaders prevent class‑loader pollution and ensure isolation.

SDK adaptation

To avoid contaminating production resources, the SDK isolates test traffic from online traffic by using shadow resources (shadow databases, topics, keys) or separate clusters. The SDK must identify, intercept, and forward test traffic, which requires bytecode‑injected logic for components such as Servlet containers, Redis clients, Kafka clients, HTTP clients, and MySQL data sources.

Class‑loader challenges

Spring Boot’s LaunchedURLClassLoader loads application classes, while the agent’s classes are loaded by the AppClassLoader, creating a bidirectional dependency that the parent‑delegate model cannot resolve. The solution is to introduce an AgentClassLoader between the AppClassLoader and the agent plugins, ensuring all enhancement classes are loaded uniformly.

Current status and future work

The Java Agent library now supports multiple business lines, handling Jetty, Kafka, Redis, and MySQL traffic, with dynamic configuration and monitoring. Ongoing work includes reducing startup overhead, further supporting link diagnosis, and integrating with service mesh and other Java Agent products.