Dapr Workflows 性能测试指南基于 k6 与 K8s 的并发压测方案全解析【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr导读本文围绕 Dapr 仓库中的 tests/perf/workflows/README.md 展开完整讲解 Dapr Workflows 性能测试套件的设计思路与运行机制。测试由 Go 测试框架驱动、k6 施加负载覆盖恒定虚拟用户数、恒定迭代数、最大并发、延迟工作流与不同负载大小等常见模式。读完本文你将掌握每个测试场景的 VU/迭代组合、sum_series_wf/sum_parallel_wf/state_wf/delay_wf等被测工作流的构造方式、App 与 Sidecar 资源监控的采集方法以及如何利用tests/perf/report将 k6 JSON 报告渲染成可视化图表。测试目标与整体架构该测试套件的目标是在 Kubernetes 集群上部署perf-workflowsapp应用及其 Dapr Sidecar通过 k6 向工作流应用发送 HTTP 请求评估 Dapr Workflows 在常见负载模式下的性能表现。测试结果不仅包含 k6 自身的延迟与吞吐指标还同步采集 App 与 Sidecar 的 CPU/内存使用量及重启次数最终汇总成一张摘要表并输出图表到 tests/perf/report/charts/v1.16.3/workflows/。整个套件由三部分协作完成Go 测试驱动workflow_test.go 负责部署应用、准备 k6 环境、执行压测并采集资源数据k6 脚本test.js 定义各类压测场景VU 数、迭代数、执行器与超时时间报告渲染tests/perf/report 下的charts.go将 gotestsum 的 JSON 报告转换为 PNG 图表。术语表Glossary术语含义VUVirtual User同一时刻并发运行的工作流数量Iterations工作流运行的总次数Req_Duration完成一次工作流运行所花费的时间SidecarDapr Sidecar 进程测试计划部署与公共流程部署拓扑所有测试共享同一套部署拓扑在 Kubernetes 集群上部署单实例的perf-workflowsapp镜像名为perf-workflowsapp应用端口与 Ingress 端口均为 3000并启用 Dapr Sidecar。资源请求/限制通过AppDescription结构体中的App*与Dapr*字段配置具体数值定义在 workflow_test.go 的TestMain中字段值DaprCPULimit1.0DaprCPURequest0.5DaprMemoryLimit2GiDaprMemoryRequest1GiAppCPULimit2.0AppCPURequest1.0AppMemoryLimit2GiAppMemoryRequest1GiReplicas1此外测试还定义了一个scaledAppNameperf-workflowsapp-scaled以scaledReplicas 3副本部署用于多实例场景下验证工作流与活动跨实例分布的表现。所有场景的公共流程使用 k6 向工作流应用发送 HTTP 请求在开始加压之前初始化工作流运行时收集 k6 指标以及 App/Sidecar 的资源使用量与重启次数写入摘要表测试结束后将指标汇总至 tests/perf/report/charts/v1.16.3/workflows/ 下的图表。每次子测试的核心执行流程封装在testWorkflow()函数中workflow_test.go若restart为 true先通过tr.Platform.Restart(testAppName)重启应用以清空上一次运行的内存与状态获取应用的外部 Ingress URL调用utils.HealthCheckApps(externalURL)确认应用健康调用http://externalURL/start-workflow-runtime初始化工作流运行时对多副本应用循环调用scaledReplicas * 3次确保所有实例都已初始化随后 sleep 5 秒构造 k6 运行配置K6RunConfig目标 URL、场景名、工作流名、工作流输入、通过率检查表达式调用runk6test()执行压测对于负载大小测试payloadTest为 true额外将输入字节数换算为 KB 输出到摘要表通过addTestResults()采集资源数据见下文并写入摘要表最后table.Flush()落盘。资源与指标采集addTestResults()workflow_test.go通过tr.Platform提供的三个方法采集GetAppUsage(testAppName)应用 Pod 的内存MB与 CPUm使用量GetSidecarUsage(testAppName)Sidecar 的内存与 CPU 使用量GetTotalRestarts(testAppName)应用重启总次数。同时将 k6 汇总指标写入摘要表包括VUs Max、Iterations Count、HTTP 请求时长Req Durationms、HTTP 请求等待时长Req Waitingms与迭代时长Iteration Durationms。k6 场景定义详解test.js 定义了完整的场景库。每个场景使用shared-iterations执行器即固定 VU 数共享固定总量的迭代所有迭代完成后场景结束场景名VUsIterationsmaxDurationt_30_30030300200st_60_30060300380st_90_30090300380st_350_140035014001000st_110_440110440450st_80_80080800420st_500_10000500100003600s场景名遵循t_workflowCount_iterations的命名约定。运行时会通过__ENV.SCENARIO环境变量选择唯一启用的场景enabledScenarios[__ENV.SCENARIO]。脚本通过 k6 环境变量接收配置TARGET_URL工作流运行接口地址http://app/run-workflowSCENARIO场景名如t_30_300WORKFLOW_NAME要运行的工作流名WORKFLOW_INPUT工作流输入数字或负载大小RATE_CHECK通过率阈值表达式如rate1作为 k6 的checksthreshold 生效。压测主流程execute()将workflow_name与workflow_input封装为 JSON向${TARGET_URL}/${iterationInTest}发起 HTTP POST 请求并以响应状态码 2xx 作为通过检查check。teardown()阶段会调用 Dapr Sidecar 的http://127.0.0.1:${DAPR_HTTP_PORT}/v1.0/shutdown接口触发优雅关闭。五大测试场景逐一解析测试函数均通过//go:build perf构建标签隔离仅在-tagsperf下编译并使用testWorkflow()通用执行器驱动。各测试传入rateChecks矩阵如rate1作为每次运行的 k6 通过率要求。TestWorkflowWithConstantVUs恒定 VU 数被测工作流sum_series_wf包含 5 个链式串行活动每个活动执行数值计算并把结果返回给工作流。场景设计输入[100]场景[t_30_300, t_30_300, t_30_300]30 VU、300 总迭代同一场景连续运行 3 次不重启应用restartfalse用于观察多次连续运行下延迟与资源使用的稳定性workflow_test.go。每次运行结束后记录 k6 延迟与吞吐指标、App/Sidecar 的 CPU/内存使用量以及总重启次数。TestWorkflowWithConstantIterations恒定迭代数、递增 VU被测工作流同样是sum_series_wf5 个链式数值计算活动。场景设计输入[100]场景[t_30_300, t_60_300, t_90_300]总迭代恒定为 300VU 从 30 递增到 90每次子测试运行前重启应用以清空状态restarttrue从而隔离在相同总工作量下增大 VU 数对延迟与资源使用的影响workflow_test.go。TestSeriesWorkflowWithMaxVUs串行工作流高并发压测被测工作流sum_series_wf5 个链式活动以更高的 VU 数对串行工作流施压。场景设计输入[100]场景[t_350_1400]350 VU、1400 迭代校验所有工作流实例均成功完成并记录 App/Sidecar 资源使用量与延迟指标workflow_test.go。TestParallelWorkflowWithMaxVUs并行工作流高并发压测被测工作流sum_parallel_wf包含 5 个并行执行的活动其结果由工作流聚合——即经典的扇出/扇入fan-out/fan-in模式。场景设计输入[100]场景[t_110_440]110 VU、440 迭代重点考察负载下扇出/扇入行为的性能表现同样记录 k6 指标与资源使用量workflow_test.go。TestWorkflowWithDifferentPayloads不同负载大小被测工作流state_wf执行状态操作内部由 3 个活动组成活动 1将指定大小的数据保存到配置的状态存储state store活动 2读回已保存的数据活动 3删除该数据。工作流以数据大小作为输入并将该大小的字符串作为负载传给活动。场景设计场景恒定为[t_30_300]负载大小取[10000, 50000, 100000]字节对每种负载大小运行相同的 k6 场景记录延迟、吞吐与 App/Sidecar 资源使用将有效负载大小输出到摘要表并在每次运行之间重启应用workflow_test.go。多实例与延迟工作流补充场景除 README 列出的五大场景外workflow_test.go 还实现了三个扩展场景与上述测试共用同一套testWorkflow()执行框架TestSeriesWorkflowMultiInstance / TestParallelWorkflowMultiInstance针对 3 副本的scaledAppName部署运行sum_series_wft_30_300与sum_parallel_wft_110_440验证工作流与并行活动的扇出/扇入跨多个 Dapr 实例分布时的表现workflow_test.go。TestDelayWorkflowsAtScale延迟工作流压测运行delay_wf输入5000表示延迟毫秒数5 秒场景为t_500_10000500 VU、10000 迭代maxDuration 3600s考察大量工作流同时处于等待/延时状态时的运行时稳定性workflow_test.go。这也是t_500_10000场景在 test.js 中单独存在的用途。如何运行 Workflows 性能测试性能测试的构建与运行入口集中在 tests/dapr_tests.mkPERF_TEST_APPS中包含workflowsapp即性能测试应用清单tests/dapr_tests.mkPERF_TESTS中包含workflowstests/dapr_tests.mkMakefile 通过genPerfTestRun模板为每个性能测试生成test-perf-name目标tests/dapr_tests.mk运行方式为make test-perf-workflows该目标要求先满足check-e2e-env与test-deps前置条件内部使用gotestsum以-tagsperf ./tests/perf/workflows/...编译执行并生成 JSON/JUnit 格式的测试输出--jsonfile、--junitfile超时上限为 2 小时、-count1禁用测试缓存。整体链路perf-build-deploy-run则串联init-build-deploy → setup-test-components → build-perf-app-all → push-perf-app-all → test-perf-alltests/dapr_tests.mk。执行环境依赖DAPR_TEST_NAMESPACE、DAPR_TEST_TAG、DAPR_TEST_REGISTRY等环境变量指定目标集群与镜像仓库若要单独挑选某个性能测试可设置DAPR_PERF_TEST环境变量tests/dapr_tests.mk。结果可视化从 JSON 报告到图表图表分类与平均规则性能测试会重复运行同一场景如TestWorkflowWithConstantVUs/[T_30_300]:_运行 3 次tests/perf/report 下的charts.go会归一化子测试名剥离:_/:_#NN后缀使同一逻辑测试的所有运行共享同一 key如TestWorkflowWithConstantVUs_T_30_300若同一逻辑测试有多次运行则按指标逐项求平均生成带_avg后缀的平均图表并额外生成*_duration_comparison.png比较各次运行的延迟差异若只有一次运行则直接生成不带_avg的图表。图表类型针对每个测试会生成以下图表示例见 tests/perf/report/charts/v1.16.3/workflows/时长分解图*_avg_duration_breakdown.png/*_avg_duration_low.pngX 轴为百分位min/med/avg/p90/p95/maxY 轴为秒折线来自 k6 指标http_req_connecting、http_req_tls_handshaking、http_req_sending、http_req_receiving、http_req_blocked、http_req_waiting、http_req_duration、iteration_duration与http_req_failed。全范围图展示整体含延迟工作流的长时间http_req_waiting低延迟图则动态缩放到 0N 秒窗口以观察短耗时阶段。性能摘要图*_avg_summary.png柱状展示成功率checks.rate * 100、失败率与 VUsvus_max.values.max回答该场景是否通过、驱动测试需要多少虚拟用户。吞吐图*_avg_throughput.png迭代/秒作为标题柱状展示接收数据速率data_received.values.rate / 1024KB/s与发送数据速率data_sent.values.rate / 1024KB/s。数据量图*_avg_data_volume.png按总量自动选择单位1MB 用 KB、≥1GB 用 GB、否则用 MB柱状展示整个测试生命周期的收发总字节数便于对比不同负载大小或不同时长的场景。运行间时长对比图*_duration_comparison.pngX 轴为 Run 1/2/3…Y 轴为延迟ms折线为每次运行的 p50中位数与 p95尾延迟用于判断运行稳定性折线平坦说明性能一致出现尖峰或趋势则说明运行间存在波动。本地生成图表charts.go读取 gotestsum JSON 报告支持直接读取.gz压缩包并输出 PNG 到charts/version/api/cd tests/perf/report go run . -input data/v1.18.0/test_report_perf.json.gz -version v1.18.0常用参数-input报告路径默认./test_report_perf.json、-versioncharts/下的输出子目录默认master、-infra运行基础设施描述CI 传入 tests/test-infra/perf-infra-description.txt 以保证结果可比、-manifest额外输出 docs 站点使用的 manifest JSON。设置CHARTS_DEBUG1可查看测试分类的详细输出。每个 API 的 README 顶部还会生成Throughput per resource表各场景的迭代/秒、App 与 Sidecar 的 CPU/内存消耗以及每 CPU 核心、每 GB 内存的迭代数app sidecar 合并这是跨场景、跨版本比较效率的核心指标。结果归档与版本管理策略按 tests/perf/report/charts/README.md 的说明性能结果的事实来源source of truth是 CI 运行产生的 gotestsum JSON 报告而非渲染后的 PNG每个版本的压缩报告提交在tests/perf/report/data/version/test_report_perf.json.gz渲染图表作为perf-charts-version.zip发布到对应版本同时将图表与manifest.json推送到perf-charts分支的minor/目录如v1.18/默认分支不提交新版本的完整图表集每个版本数 MB 且 PNG 无法事后重新生成因为 JSON 报告可以随时用当前图表代码重新渲染。小结Dapr Workflows 性能测试套件是一套完整、可复现的压测方案以 Go 测试编排生命周期、以 k6shared-iterations场景控制并发模型、以摘要表与图表沉淀结果。通过本指南你可以按需扩展possibleScenarios或新增测试函数复现并对比不同版本、不同基础设施下 Dapr Workflows 的串行链、并行扇出/扇入、状态读写与延迟场景的性能表现。若需深入底层实现可继续阅读 pkg/runtime/wfengine 下 Dapr Workflows 引擎源码以及 tests/e2e/workflows/workflow_test.go 中对应的端到端功能验证。【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/12 22:52:30 · 阅读 1.2k Dapr Workflows 性能测试指南：基于 k6 与 K8s 的并发压测方案全解析
Dapr Workflows 性能测试指南基于 k6 与 K8s 的并发压测方案全解析【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr导读本文围绕 Dapr 仓库中的 tests/perf/workflows/README.md 展开完整讲解 Dapr Workflows 性能测试套件的设计思路与运行机制。测试由 Go 测试框架驱动、k6 施加负载覆盖恒定虚拟用户数、恒定迭代数、最大并发、延迟工作流与不同负载大小等常见模式。读完本文你将掌握每个测试场景的 VU/迭代组合、sum_series_wf/sum_parallel_wf/state_wf/delay_wf等被测工作流的构造方式、App 与 Sidecar 资源监控的采集方法以及如何利用tests/perf/report将 k6 JSON 报告渲染成可视化图表。测试目标与整体架构该测试套件的目标是在 Kubernetes 集群上部署perf-workflowsapp应用及其 Dapr Sidecar通过 k6 向工作流应用发送 HTTP 请求评估 Dapr Workflows 在常见负载模式下的性能表现。测试结果不仅包含 k6 自身的延迟与吞吐指标还同步采集 App 与 Sidecar 的 CPU/内存使用量及重启次数最终汇总成一张摘要表并输出图表到 tests/perf/report/charts/v1.16.3/workflows/。整个套件由三部分协作完成Go 测试驱动workflow_test.go 负责部署应用、准备 k6 环境、执行压测并采集资源数据k6 脚本test.js 定义各类压测场景VU 数、迭代数、执行器与超时时间报告渲染tests/perf/report 下的charts.go将 gotestsum 的 JSON 报告转换为 PNG 图表。术语表Glossary术语含义VUVirtual User同一时刻并发运行的工作流数量Iterations工作流运行的总次数Req_Duration完成一次工作流运行所花费的时间SidecarDapr Sidecar 进程测试计划部署与公共流程部署拓扑所有测试共享同一套部署拓扑在 Kubernetes 集群上部署单实例的perf-workflowsapp镜像名为perf-workflowsapp应用端口与 Ingress 端口均为 3000并启用 Dapr Sidecar。资源请求/限制通过AppDescription结构体中的App*与Dapr*字段配置具体数值定义在 workflow_test.go 的TestMain中字段值DaprCPULimit1.0DaprCPURequest0.5DaprMemoryLimit2GiDaprMemoryRequest1GiAppCPULimit2.0AppCPURequest1.0AppMemoryLimit2GiAppMemoryRequest1GiReplicas1此外测试还定义了一个scaledAppNameperf-workflowsapp-scaled以scaledReplicas 3副本部署用于多实例场景下验证工作流与活动跨实例分布的表现。所有场景的公共流程使用 k6 向工作流应用发送 HTTP 请求在开始加压之前初始化工作流运行时收集 k6 指标以及 App/Sidecar 的资源使用量与重启次数写入摘要表测试结束后将指标汇总至 tests/perf/report/charts/v1.16.3/workflows/ 下的图表。每次子测试的核心执行流程封装在testWorkflow()函数中workflow_test.go若restart为 true先通过tr.Platform.Restart(testAppName)重启应用以清空上一次运行的内存与状态获取应用的外部 Ingress URL调用utils.HealthCheckApps(externalURL)确认应用健康调用http://externalURL/start-workflow-runtime初始化工作流运行时对多副本应用循环调用scaledReplicas * 3次确保所有实例都已初始化随后 sleep 5 秒构造 k6 运行配置K6RunConfig目标 URL、场景名、工作流名、工作流输入、通过率检查表达式调用runk6test()执行压测对于负载大小测试payloadTest为 true额外将输入字节数换算为 KB 输出到摘要表通过addTestResults()采集资源数据见下文并写入摘要表最后table.Flush()落盘。资源与指标采集addTestResults()workflow_test.go通过tr.Platform提供的三个方法采集GetAppUsage(testAppName)应用 Pod 的内存MB与 CPUm使用量GetSidecarUsage(testAppName)Sidecar 的内存与 CPU 使用量GetTotalRestarts(testAppName)应用重启总次数。同时将 k6 汇总指标写入摘要表包括VUs Max、Iterations Count、HTTP 请求时长Req Durationms、HTTP 请求等待时长Req Waitingms与迭代时长Iteration Durationms。k6 场景定义详解test.js 定义了完整的场景库。每个场景使用shared-iterations执行器即固定 VU 数共享固定总量的迭代所有迭代完成后场景结束场景名VUsIterationsmaxDurationt_30_30030300200st_60_30060300380st_90_30090300380st_350_140035014001000st_110_440110440450st_80_80080800420st_500_10000500100003600s场景名遵循t_workflowCount_iterations的命名约定。运行时会通过__ENV.SCENARIO环境变量选择唯一启用的场景enabledScenarios[__ENV.SCENARIO]。脚本通过 k6 环境变量接收配置TARGET_URL工作流运行接口地址http://app/run-workflowSCENARIO场景名如t_30_300WORKFLOW_NAME要运行的工作流名WORKFLOW_INPUT工作流输入数字或负载大小RATE_CHECK通过率阈值表达式如rate1作为 k6 的checksthreshold 生效。压测主流程execute()将workflow_name与workflow_input封装为 JSON向${TARGET_URL}/${iterationInTest}发起 HTTP POST 请求并以响应状态码 2xx 作为通过检查check。teardown()阶段会调用 Dapr Sidecar 的http://127.0.0.1:${DAPR_HTTP_PORT}/v1.0/shutdown接口触发优雅关闭。五大测试场景逐一解析测试函数均通过//go:build perf构建标签隔离仅在-tagsperf下编译并使用testWorkflow()通用执行器驱动。各测试传入rateChecks矩阵如rate1作为每次运行的 k6 通过率要求。TestWorkflowWithConstantVUs恒定 VU 数被测工作流sum_series_wf包含 5 个链式串行活动每个活动执行数值计算并把结果返回给工作流。场景设计输入[100]场景[t_30_300, t_30_300, t_30_300]30 VU、300 总迭代同一场景连续运行 3 次不重启应用restartfalse用于观察多次连续运行下延迟与资源使用的稳定性workflow_test.go。每次运行结束后记录 k6 延迟与吞吐指标、App/Sidecar 的 CPU/内存使用量以及总重启次数。TestWorkflowWithConstantIterations恒定迭代数、递增 VU被测工作流同样是sum_series_wf5 个链式数值计算活动。场景设计输入[100]场景[t_30_300, t_60_300, t_90_300]总迭代恒定为 300VU 从 30 递增到 90每次子测试运行前重启应用以清空状态restarttrue从而隔离在相同总工作量下增大 VU 数对延迟与资源使用的影响workflow_test.go。TestSeriesWorkflowWithMaxVUs串行工作流高并发压测被测工作流sum_series_wf5 个链式活动以更高的 VU 数对串行工作流施压。场景设计输入[100]场景[t_350_1400]350 VU、1400 迭代校验所有工作流实例均成功完成并记录 App/Sidecar 资源使用量与延迟指标workflow_test.go。TestParallelWorkflowWithMaxVUs并行工作流高并发压测被测工作流sum_parallel_wf包含 5 个并行执行的活动其结果由工作流聚合——即经典的扇出/扇入fan-out/fan-in模式。场景设计输入[100]场景[t_110_440]110 VU、440 迭代重点考察负载下扇出/扇入行为的性能表现同样记录 k6 指标与资源使用量workflow_test.go。TestWorkflowWithDifferentPayloads不同负载大小被测工作流state_wf执行状态操作内部由 3 个活动组成活动 1将指定大小的数据保存到配置的状态存储state store活动 2读回已保存的数据活动 3删除该数据。工作流以数据大小作为输入并将该大小的字符串作为负载传给活动。场景设计场景恒定为[t_30_300]负载大小取[10000, 50000, 100000]字节对每种负载大小运行相同的 k6 场景记录延迟、吞吐与 App/Sidecar 资源使用将有效负载大小输出到摘要表并在每次运行之间重启应用workflow_test.go。多实例与延迟工作流补充场景除 README 列出的五大场景外workflow_test.go 还实现了三个扩展场景与上述测试共用同一套testWorkflow()执行框架TestSeriesWorkflowMultiInstance / TestParallelWorkflowMultiInstance针对 3 副本的scaledAppName部署运行sum_series_wft_30_300与sum_parallel_wft_110_440验证工作流与并行活动的扇出/扇入跨多个 Dapr 实例分布时的表现workflow_test.go。TestDelayWorkflowsAtScale延迟工作流压测运行delay_wf输入5000表示延迟毫秒数5 秒场景为t_500_10000500 VU、10000 迭代maxDuration 3600s考察大量工作流同时处于等待/延时状态时的运行时稳定性workflow_test.go。这也是t_500_10000场景在 test.js 中单独存在的用途。如何运行 Workflows 性能测试性能测试的构建与运行入口集中在 tests/dapr_tests.mkPERF_TEST_APPS中包含workflowsapp即性能测试应用清单tests/dapr_tests.mkPERF_TESTS中包含workflowstests/dapr_tests.mkMakefile 通过genPerfTestRun模板为每个性能测试生成test-perf-name目标tests/dapr_tests.mk运行方式为make test-perf-workflows该目标要求先满足check-e2e-env与test-deps前置条件内部使用gotestsum以-tagsperf ./tests/perf/workflows/...编译执行并生成 JSON/JUnit 格式的测试输出--jsonfile、--junitfile超时上限为 2 小时、-count1禁用测试缓存。整体链路perf-build-deploy-run则串联init-build-deploy → setup-test-components → build-perf-app-all → push-perf-app-all → test-perf-alltests/dapr_tests.mk。执行环境依赖DAPR_TEST_NAMESPACE、DAPR_TEST_TAG、DAPR_TEST_REGISTRY等环境变量指定目标集群与镜像仓库若要单独挑选某个性能测试可设置DAPR_PERF_TEST环境变量tests/dapr_tests.mk。结果可视化从 JSON 报告到图表图表分类与平均规则性能测试会重复运行同一场景如TestWorkflowWithConstantVUs/[T_30_300]:_运行 3 次tests/perf/report 下的charts.go会归一化子测试名剥离:_/:_#NN后缀使同一逻辑测试的所有运行共享同一 key如TestWorkflowWithConstantVUs_T_30_300若同一逻辑测试有多次运行则按指标逐项求平均生成带_avg后缀的平均图表并额外生成*_duration_comparison.png比较各次运行的延迟差异若只有一次运行则直接生成不带_avg的图表。图表类型针对每个测试会生成以下图表示例见 tests/perf/report/charts/v1.16.3/workflows/时长分解图*_avg_duration_breakdown.png/*_avg_duration_low.pngX 轴为百分位min/med/avg/p90/p95/maxY 轴为秒折线来自 k6 指标http_req_connecting、http_req_tls_handshaking、http_req_sending、http_req_receiving、http_req_blocked、http_req_waiting、http_req_duration、iteration_duration与http_req_failed。全范围图展示整体含延迟工作流的长时间http_req_waiting低延迟图则动态缩放到 0N 秒窗口以观察短耗时阶段。性能摘要图*_avg_summary.png柱状展示成功率checks.rate * 100、失败率与 VUsvus_max.values.max回答该场景是否通过、驱动测试需要多少虚拟用户。吞吐图*_avg_throughput.png迭代/秒作为标题柱状展示接收数据速率data_received.values.rate / 1024KB/s与发送数据速率data_sent.values.rate / 1024KB/s。数据量图*_avg_data_volume.png按总量自动选择单位1MB 用 KB、≥1GB 用 GB、否则用 MB柱状展示整个测试生命周期的收发总字节数便于对比不同负载大小或不同时长的场景。运行间时长对比图*_duration_comparison.pngX 轴为 Run 1/2/3…Y 轴为延迟ms折线为每次运行的 p50中位数与 p95尾延迟用于判断运行稳定性折线平坦说明性能一致出现尖峰或趋势则说明运行间存在波动。本地生成图表charts.go读取 gotestsum JSON 报告支持直接读取.gz压缩包并输出 PNG 到charts/version/api/cd tests/perf/report go run . -input data/v1.18.0/test_report_perf.json.gz -version v1.18.0常用参数-input报告路径默认./test_report_perf.json、-versioncharts/下的输出子目录默认master、-infra运行基础设施描述CI 传入 tests/test-infra/perf-infra-description.txt 以保证结果可比、-manifest额外输出 docs 站点使用的 manifest JSON。设置CHARTS_DEBUG1可查看测试分类的详细输出。每个 API 的 README 顶部还会生成Throughput per resource表各场景的迭代/秒、App 与 Sidecar 的 CPU/内存消耗以及每 CPU 核心、每 GB 内存的迭代数app sidecar 合并这是跨场景、跨版本比较效率的核心指标。结果归档与版本管理策略按 tests/perf/report/charts/README.md 的说明性能结果的事实来源source of truth是 CI 运行产生的 gotestsum JSON 报告而非渲染后的 PNG每个版本的压缩报告提交在tests/perf/report/data/version/test_report_perf.json.gz渲染图表作为perf-charts-version.zip发布到对应版本同时将图表与manifest.json推送到perf-charts分支的minor/目录如v1.18/默认分支不提交新版本的完整图表集每个版本数 MB 且 PNG 无法事后重新生成因为 JSON 报告可以随时用当前图表代码重新渲染。小结Dapr Workflows 性能测试套件是一套完整、可复现的压测方案以 Go 测试编排生命周期、以 k6shared-iterations场景控制并发模型、以摘要表与图表沉淀结果。通过本指南你可以按需扩展possibleScenarios或新增测试函数复现并对比不同版本、不同基础设施下 Dapr Workflows 的串行链、并行扇出/扇入、状态读写与延迟场景的性能表现。若需深入底层实现可继续阅读 pkg/runtime/wfengine 下 Dapr Workflows 引擎源码以及 tests/e2e/workflows/workflow_test.go 中对应的端到端功能验证。【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考