Architecture of the Load Density framework, detailing entry interfaces, action execution, multi-protocol load generation via Locust, and test result proces
flowchart TD
subgraph Entry["入口介面"]
CLI[CLI]
MCP[MCP Server]
GUI[GUI]
SOCK[控制 Socket]
end
Entry -- "動作 JSON" --> EXEC["動作 Executor<br/>(LD_* 派發 + 安全 builtin)"]
EXEC -- "start_test" --> WRAPPER["locust_wrapper_proxy<br/>(每協定 task store)"]
WRAPPER --> HTTP["HTTP / FastHttp"]
WRAPPER --> WS["WebSocket"]
WRAPPER --> GRPC["gRPC"]
WRAPPER --> MQTT["MQTT"]
WRAPPER --> RAW["原生 TCP / UDP"]
HTTP -- "Locust 事件" --> BUS([Locust Event Bus])
WS --> BUS
GRPC --> BUS
MQTT --> BUS
RAW --> BUS
BUS --> REC["test_record_instance"]
BUS --> METRICS["Prometheus / InfluxDB / OTel"]
REC --> REPORTS["HTML / JSON / XML / CSV / JUnit / Summary 報告"]
REC --> SQLITE[("SQLite 持久化<br/>(跨次比對)")]The architecture of the Load Density framework, from various input interfaces (CLI, GUI, MCP Server, Control Socket) to the action executor, protocol-specific load generation wrappers (HTTP, WebSocket, gRPC, MQTT, Raw TCP/UDP), integration with Locust Event Bus, and finally, test record instances for reporting and metrics collection (Prometheus, InfluxDB, OTel, SQLite).
When designing or understanding a comprehensive load testing framework that supports multiple protocols, requires flexible input methods, integrates with a robust load testing engine like Locust, and provides detailed reporting and metrics capabilities.
This architecture can be adapted by adding new protocol handlers, integrating different load testing engines, extending the reporting formats, or incorporating alternative metrics monitoring systems. The modular design allows for swapping components like the persistence layer or adding more sophisticated scheduling mechanisms.