- 用了哪个智能体：没有使用任何智能体（没有
AssistantAgent/ 自定义 Agent 参与）。 - 调用了哪些模块：
- 前端页面：
frontend/src/views/performance-test/http-load-test.vue - 前端 API：
frontend/src/api/performanceTest.ts - 后端路由：
backend/app/api/v1/endpoints/performance_test.py - HTTP 客户端：
httpx.AsyncClient - 并发调度：
asyncio（worker + event stop）
- 前端页面：
- 用了什么大模型：没有使用大模型（不调用 DeepSeek / Qwen / LLM）。
- 核心能力：指定 URL + 方法 + 并发数 + 时长，后端持续发请求并统计
QPS / P50/P95/P99 / error_rate / 状态码分布。
详细调用关系（文字版）
- 前端点击"开始压测"，调用
performanceTestApi.run()。 - 请求发到
POST /api/v1/performance-test/run。 - 后端按
concurrent_users创建多个_worker协程。 - 每个 worker 在时长内循环调用
_run_single_request（httpx发请求）。 - 到
duration_seconds后触发stop_event，等待所有 worker 结束。 - 汇总结果并计算指标，生成
report_summary（规则文案，不是 AI）。 - 返回 JSON 给前端展示。
框架图（模块视角）
当前真实生效路径（精简图）
| 维度 | 内置 HTTP 压测（当前项目） | JMeter | k6 |
|---|---|---|---|
| 上手速度 | 最快，页面填参数直接跑 | 中等，GUI 配置后执行 | 中等，需写 JS 脚本 |
| 适用人群 | 研发/测试快速自检 | 测试工程师、传统压测团队 | 偏工程化团队、DevOps |
| 协议能力 | 仅 HTTP 基础方法 | 很丰富（HTTP/JDBC/FTP等插件生态） | 以 HTTP/WS 为主，现代接口友好 |
| 场景编排 | 基础（并发 + 时长） | 强（线程组、控制器、参数化、关联） | 强（代码级场景、阶段/阈值、自定义逻辑） |
| 数据驱动 | 基础（headers/body 手填） | 强（CSV 参数化、函数、前后置处理） | 强（代码生成数据、外部数据源） |
| 断言与检查 | 基础（状态码/成功率） | 强（响应断言、提取器、后置脚本） | 强（check、阈值 threshold） |
| 报告深度 | 中等偏基础（QPS、P50/P95/P99、错误率） | 强（多图表、聚合报告，插件丰富） | 强（趋势、阈值结果，Cloud 更完整） |
| 资源监控 | 无内建（仅提示外部监控） | 可接插件/外部 APM | 可接 Prometheus/Grafana/Cloud |
| 分布式压测 | 不支持 | 支持（Master/Slave 或多机） | 支持（多实例、云端执行） |
| CI/CD 集成 | 一般（手工或自写脚本调接口） | 可集成但偏重 | 很好（CLI + 脚本天然适配流水线） |
| 可重复性/版本化 | 一般（UI 配置为主） | 一般（.jmx 可版本化） | 强（脚本即版本） |
| 可扩展性 | 低到中（改后端代码） | 高（插件生态） | 高（代码扩展、模块化） |
| 学习/维护成本 | 最低 | 中到高 | 中 |
什么时候用内置压测
- 需要 5 分钟内验证接口是否抗压（冒烟/回归前快速检查）
- 关注核心指标：
QPS、P95、错误率是否明显退化 - 团队成员不熟悉专业压测工具，希望零学习成本
- 开发联调期，频繁改接口，需要即时反馈
什么时候切到 JMeter / k6
- 需要 复杂业务链路（登录鉴权、上下文关联、数据参数化、事务组合）
- 需要 稳定复现与长期基线（版本对比、环境对比、容量规划）
- 需要 分布式高并发（单机压不动或目标并发超出单机能力）
- 需要 更完整报告与监控联动（Grafana/APM/告警阈值）
- 需要纳入 CI/CD 质量门禁（自动失败阈值、趋势追踪）
选型建议（实操）
- 日常开发/冒烟：先用内置压测（快）。
- 提测前/发布前：用 k6 或 JMeter 做标准场景回归。
- 高并发容量评估：直接用专业工具（优先 k6 脚本化，或已有 JMeter 体系就沿用）。
- 团队偏代码化与流水线：优先 k6。
- 团队偏可视化配置与传统测试流程：优先 JMeter。