Using Claude 4.5 + Nano Banana Pro to Reverse‑Engineer Apache JMeter’s Architecture

Overview

Large language models (LLMs) combined with autonomous agents were used to reverse‑engineer the legacy code of Apache JMeter, an open‑source Java‑based performance testing tool with hundreds of thousands of lines, into a series of high‑resolution design diagrams.

Overall Architecture

JMeter is a pure‑Java, open‑source application focused on load testing, functional testing, and multi‑protocol support (HTTP/HTTPS, SOAP/REST, FTP, JDBC, LDAP, JMS, SMTP/POP3/IMAP, TCP, etc.)[ref:4]. It adopts a layered architecture.

Core Design Patterns

Composite Pattern – Tree Structure

HashTree : basic tree where each element is both a node and the key for the next level.

ListedHashTree : preserves element order to guarantee execution sequence.

Strategy Pattern – TestElement Interface

All test elements implement the TestElement interface, forming a unified component model.

Chain of Responsibility – Execution Order

0. Configuration Elements
1. Pre‑Processors
2. Timers
3. Sampler
4. Post‑Processors (only if SampleResult is not null)
5. Assertions (only if SampleResult is not null)
6. Listeners (only if SampleResult is not null)

This strict order ensures predictable and consistent test flows.

Core Engine Architecture

StandardJMeterEngine is the core execution engine responsible for running JMeter tests in GUI, CLI (headless), and distributed modes, supporting remote execution, managing thread lifecycles, and coordinating test element execution.

Multithread Framework

Each thread executes the test plan independently.

Supports concurrent sampling and multiple thread groups.

Ramp‑up control prevents overload at startup[ref:9].

Component Layer Architecture

Sampler Layer

Samplers send requests to servers. Built‑in types include:

HTTP Request (supports SOAP/REST)

FTP Request

JDBC Request

Java Object Request

JMS Request

LDAP Request

Mail Request

TCP Request

Debug Sampler

Dummy Sampler

Logic Controller Layer controls test flow (details omitted for brevity).

Configuration Element Layer

Configuration elements apply only to their branch and sub‑branches.

Child branches override parent settings.

Listener Layer uses the Observer pattern to collect and display test results.

Extensibility Design

Plugin System

Plugins inherit core abstract classes (e.g., AbstractSampler) and implement specific interfaces ( Sampler, Controller, Listener).

Registration is performed via saveservice.properties.

Custom GUI components are supported.

Function and Variable System

Each thread has its own variable copy (thread‑local); variables are referenced as ${variable_name} and can be updated dynamically.

Built‑in functions include ${__property()}, ${__threadNum()}, ${__time()}, etc.; custom functions can be added via the Function interface.

Properties have global scope, defined in jmeter.properties or overridden on the command line with jmeter -Jproperty=value.

Data‑Flow Architecture

Illustrates request‑response flow and result aggregation flow.

Distributed Architecture

Master‑Slave Mode uses RMI for communication: the master sends the test plan to slaves, slaves execute and return results, and the master aggregates them.

Remote Execution Flow

Master loads the test plan.

Serializes and sends it to all slaves.

Each slave starts a StandardJMeterEngine .

Slaves execute tests in parallel.

Results are sent back to the master.

Master aggregates and displays the results.

Code Organization

Key packages include: org.apache.jorphan.collections – HashTree implementation[ref:60]. org.apache.jmeter.save – test plan serialization. org.apache.jmeter.util – utility classes. org.apache.jmeter.reporters – result reporting components.

Advanced Features

HTTP(S) Test Script Recorder implements a proxy mode to record requests. Core capabilities:

Dynamic HTTPS certificate generation (Java 8+)[ref:1].

Request filtering with include/exclude regular expressions.

Automatic grouping based on time intervals.

Variable substitution via User Defined Variables.

Binary POST data capture.

Dynamic HTML Report (JMeter 5.x) is built with JavaScript/jQuery, supports custom charts, and works fully offline.

DSL Support (JMeter 5.6+) provides Kotlin/Java DSL for programmatic test plan construction, mirroring the test tree structure, enabling version control, automation, and a “Copy Code” feature.

Performance Optimizations

Resource Management

Connection pool with HTTP keep‑alive.

Automatic cookie handling.

Result caching for offline analysis and replay.

CLI Mode Optimizations

Eliminates GUI overhead.

Reduces memory consumption.

Improves concurrency, suitable for large‑scale production testing[ref:4].

Distributed Load Distribution

Horizontal scaling of test capacity.

Avoids single‑point bottlenecks.

Simulates geographically distributed users.

Design Pattern Summary

JMeter architecture employs Composite, Strategy, Observer, Template Method, Proxy, Factory, Chain of Responsibility, and Singleton patterns.

Architectural Advantages

Highly modular with clear interfaces and separation of responsibilities.

Strong extensibility via a plugin mechanism.

Protocol‑agnostic abstraction layer.

Native support for distributed load testing.

Cross‑platform pure Java implementation.

Programmable via scripts and DSL.

Flexible configuration hierarchy and variable system.

Rich visualization through listeners and dynamic reports.

Conclusion

Apache JMeter is a well‑designed performance testing framework whose architecture—characterized by a tree‑like component model, a unified TestElement interface, a robust engine, a multithread framework, an extensible plugin system, strict execution order, extensive protocol support, and powerful result visualization—demonstrates how layered design and systematic application of design patterns enable a flexible, scalable, and maintainable testing tool.