Dapr 性能测试运行实战：本地环境、CI 流程与 Grafana 指标可视化-迪斯科星球

Dapr 性能测试运行实战：本地环境、CI 流程与 Grafana 指标可视化

【免费下载链接】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/docs/running-perf-tests.md 为主线，系统讲解如何在本地开发环境中构建并部署自定义 Dapr 运行时、在 Kubernetes（Kind / Minikube）集群上运行 Fortio 与 k6 两类负载测试、通过 GitHub Actions 触发 CI 性能测试，以及借助 Prometheus + Grafana 将延迟、吞吐、CPU 与内存指标可视化。读完本文，你将掌握由make目标驱动的整套性能测试工作流，包括环境准备、测试应用镜像构建、测试筛选、报告图表生成与测试数据清理，并了解每一条命令背后的源码实现与默认参数。

一、性能测试概览：测什么、怎么测

Dapr 的性能测试（performance tests）目标是在给定硬件环境下，评估 Dapr 的延迟（latency）、资源占用（resource usage）与处理时间（processing time）。测试由 Go 测试框架驱动，通过-tags=perf构建标记与普通单元测试、E2E 测试隔离，负载生成由两类工具承担：

Fortio：用于基于 Fortio 的 HTTP/gRPC 压测场景，对应的测试应用是tester；
k6：用于脚本化负载场景（如工作流、订阅类测试），对应的测试应用是k6-custom，需要额外安装 k6-operator。

从 tests/dapr_tests.mk 可以看到当前仓库定义的完整性能测试套件（PERF_TESTS）：

actor_activation actor_double_activation actor_id_scale actor_reminder actor_timer actor_type_scale configuration pubsub_bulk_publish_grpc pubsub_bulk_publish_http pubsub_publish_grpc pubsub_publish_http pubsub_subscribe_http scheduler service_invocation_grpc service_invocation_http state_get_grpc state_get_http workflows

这些测试目录均位于 tests/perf 下，例如actor_activation/、service_invocation_http/、workflows/等，每个目录是一个独立的 Go 测试包。

二、在本地开发环境运行性能测试

2.1 前置条件

运行性能测试前需要准备：

Kubernetes 集群：Minikube 或 Kind 均可。
- 使用 Kind 时，可直接运行make setup-kind创建集群与本地 registry。该命令（定义于 tests/dapr_tests.mk 的setup-kind目标）会执行：
  - kind create cluster --config ./tests/config/kind.yaml --name $(DAPR_TEST_KIND_CLUSTER_NAME)，其中DAPR_TEST_KIND_CLUSTER_NAME默认值为kind，因此默认集群上下文名为kind-kind；
  - 启动本地 registry 容器：docker run -d --restart=always -p $(DAPR_TEST_REGISTRY_PORT):$(DAPR_TEST_REGISTRY_PORT) --name kind-registry registry:2，并将它接入kind网络；
  - 安装 metrics-server（--kubelet-insecure-tls），供资源指标采集使用。
- 注意：make setup-kind创建的默认集群名kind-kind会被自动用于判断测试是否运行在本地 Kind 集群中。如需改名，先执行export DAPR_TEST_KIND_CLUSTER_NAME=mycluster（对应上下文kind-mycluster）再运行make setup-kind。
- 注意（macOS Ventura 及以上）：本地 registry 默认端口5000可能被 AirPlay Receiver 服务占用，可用export DAPR_TEST_REGISTRY_PORT=5001换端口后执行make setup-kind。
- Kind 环境下，运行make describe-kind-env可打印出所需的 export 命令（包括MINIKUBE_NODE_IP、DAPR_REGISTRY=localhost:<port>/dapr、DAPR_TAG=dev、DAPR_NAMESPACE=dapr-tests等），直接复制粘贴到终端即可。
- 使用 Minikube 时，对应有make setup-minikube（启动 4 核 4GB 集群并启用 metrics-server，Apple Silicon 下使用 qemu 驱动）与make describe-minikube-env两个目标。
Dapr 开发环境：按 docs/development/setup-dapr-development-env.md 完成搭建，并安装最新版 Helm v3。
DockerHub 账号：用于存放 Dapr 运行时镜像与测试应用镜像。
创建测试命名空间：

kubectl create namespace dapr-tests

2.2 设置环境变量

export DAPR_REGISTRY=docker.io/your_dockerhub_id export DAPR_TAG=dev export DAPR_NAMESPACE=dapr-tests # 不使用 minikube 时不要设置 DAPR_TEST_ENV export DAPR_TEST_ENV=minikube # 若测试应用希望使用不同的 registry 与 tag，取消下面注释 # export DAPR_TEST_REGISTRY=docker.io/your_dockerhub_id # export DARP_TEST_TAG=dev # export DAPR_TEST_REGISTRY_SECRET=yourself_private_image_secret

其中DAPR_TEST_REGISTRY、DAPR_TEST_TAG未显式设置时会分别回落到DAPR_REGISTRY与DAPR_TAG-$(TARGET_OS)-$(TARGET_ARCH)（见 tests/dapr_tests.mk 中的ifeq逻辑），DAPR_TEST_NAMESPACE默认等于DAPR_NAMESPACE。

Fortio 测试专用参数

下面的环境变量用于配置基于 Fortio 的测试，make test-perf-all等目标会以gotestsum的进程环境将它们传给测试程序。这些变量最终通过 tests/perf/test_params.go 中的useEnvVar机制覆盖代码内选项——即环境变量优先级高于代码默认值与手动设置的选项：

环境变量	作用	文档注释中的默认值	源码实际默认值
`DAPR_PERF_QPS`	每秒请求数	1	`defaultQPS = 1`
`DAPR_PERF_CONNECTIONS`	发送请求到 Dapr 的客户端连接数	1	`defaultClientConnections = 1`
`DAPR_TEST_DURATION`	测试时长	`"1m"`	`defaultTestDuration = "1m"`
`DAPR_PAYLOAD_SIZE`	测试载荷大小（字节/千字节）	0	`defaultPayloadSizeKB = 0`
`DAPR_SIDECAR_CPU_LIMIT`	Dapr sidecar CPU limit	4.0	`defaultSidecarCPULimit = "1.0"`
`DAPR_SIDECAR_MEMORY_LIMIT`	Dapr sidecar 内存 limit	512Mi	`defaultSidecarMemoryLimit = "256Mi"`
`DAPR_SIDECAR_CPU_REQUEST`	Dapr sidecar CPU request	0.5	`defaultSidecarCPURequest = "0.1"`
`DAPR_SIDECAR_MEMORY_REQUEST`	Dapr sidecar 内存 request	250Mi	`defaultSidecarMemoryRequest = "100Mi"`

一致性提醒：文档注释给出的 sidecar 资源默认值与当前仓库源码（tests/runner/kube_testplatform.go 中的defaultSidecar*常量）不一致，实际生效值以源码为准。这些 sidecar 资源参数会在测试部署应用时写入 Pod 的 requests/limits 中，用于观察不同资源配置下的性能表现。

对应导出命令为：

export DAPR_PERF_QPS export DAPR_PERF_CONNECTIONS export DAPR_TEST_DURATION export DAPR_PAYLOAD_SIZE export DAPR_SIDECAR_CPU_LIMIT export DAPR_SIDECAR_MEMORY_LIMIT export DAPR_SIDECAR_CPU_REQUEST export DAPR_SIDECAR_MEMORY_REQUEST

此外，tests/perf/test_params.go还支持DAPR_PAYLOAD（直接指定载荷内容），且toStrParam会在字符串转 int 失败时静默降级为 no-op，不会中断测试。

2.3 部署你的 Dapr 运行时变更

性能测试的意义在于评估你本地改动的 Dapr 代码的表现，因此需要先把本地源码构建为镜像并部署到集群：

# 构建 Linux 二进制 make build-linux # 用 Linux 二进制构建 Docker 镜像 make docker-build # 推送镜像到你的 DockerHub registry make docker-push # 将 Dapr 运行时部署到当前 Kubernetes 集群 make docker-deploy-k8s # 安装第三方软件（Redis、Kafka、Zipkin、PostgreSQL 等） make setup-3rd-party

Apple Silicon（M 芯片）注意：构建前需设置目标架构：

export TARGET_ARCH=arm64

从源码看，make build-linux（Makefile 中build-linux目标）会为daprd、injector、operator、placement、scheduler、sentry等二进制逐一执行CGO_ENABLED=$(CGO) GOOS=linux GOARCH=$(GOARCH) go build；而docker-deploy-k8s实际通过helm upgrade --install将 charts/dapr 部署到DAPR_NAMESPACE，并读取DAPR_MTLS_ENABLED（默认true）、DAPR_TEST_REGISTRY_SECRET、HA_MODE等变量，global.mtls.enabled会随之变化——这解释了后文“禁用 mTLS”步骤的由来。make setup-3rd-party则串联安装 Redis、Kafka、Zipkin、PostgreSQL（见 tests/dapr_tests.mk 的setup-3rd-party与setup-test-env-*系列目标）。

2.4 注册应用配置

make setup-app-configurations

该目标实际执行kubectl apply -f ./tests/config/dapr_observability_test_config.yaml（见 tests/dapr_tests.mk），用于在DAPR_TEST_NAMESPACE中注册测试用的 Dapr 配置。

2.5 可选：关闭追踪与 mTLS

禁用追踪（telemetry）：性能测试默认开启追踪会影响延迟数据，可通过环境变量关闭：

export DAPR_DISABLE_TELEMETRY=true

该变量在 tests/runner/kube_testplatform.go 的disableTelemetry()中解析：只有解析为布尔true时才生效。

禁用 mTLS（默认开启）：

make setup-disable-mtls

该目标应用 tests/config/dapr_mtls_off_config.yaml，关闭后可在非加密链路上测得更接近应用层的延迟数据。

2.6 注册测试组件配置

make setup-test-components

该目标（tests/dapr_tests.mk 的setup-test-components）会依次kubectl apply大量组件与配置清单，覆盖：状态存储（dapr_$(DAPR_TEST_STATE_STORE)_state.yaml等，DAPR_TEST_STATE_STORE默认postgres）、Actor 状态存储、查询状态、pubsub（dapr_$(DAPR_TEST_PUBSUB)_pubsub.yaml，默认redis）、配置存储（默认redis）、加密组件（默认jwks）、Kafka 绑定与自定义路由、订阅路由、allowlists、工作流访问控制、resiliency、内存态组件等，并在最后打印kubectl get components与kubectl get configurations以确认安装结果。测试框架还支持通过DAPR_TEST_QUERY_STATE_STORE、DAPR_TEST_CONFIG_STORE、DAPR_TEST_CRYPTO等变量切换被测后端。

2.7 构建并推送测试应用镜像

测试应用源码位于tests/apps/，性能测试应用位于tests/apps/perf/。全量构建与推送：

# 构建 tests/apps 下的性能测试应用镜像 make build-perf-app-all # 推送性能测试应用镜像到 DockerHub make push-perf-app-all

也可以按应用单独构建、推送：

make build-perf-app-<app-name> make push-perf-app-<app-name>

<app-name>取自 tests/dapr_tests.mk 中的PERF_TEST_APPS：

actorfeatures actorjava tester service_invocation_http service_invocation_grpc actor-activation-locker k6-custom pubsub_subscribe_http configuration workflowsapp jobs

重要：单独构建测试应用时，还必须构建并推送对应的压测驱动应用：

tester（build-perf-app-tester/push-perf-app-tester）：供 Fortio 类测试使用；
k6-custom（build-perf-app-k6-custom/push-perf-app-k6-custom）：供 k6 类测试使用。

这些目标（build-perf-app-*/push-perf-app-*）由 tests/dapr_tests.mk 中的genPerfTestAppImageBuild/genPerfAppImagePush模板批量生成，底层调用$(RUN_BUILD_TOOLS) perf build/push，并前置检查DAPR_TEST_REGISTRY与DAPR_TEST_TAG是否已设置。

2.8 （k6 测试）安装 k6-operator

若运行 k6 类测试，需要先安装 k6-operator：

make setup-test-env-k6

该目标（见 tests/dapr_tests.mk）会应用 tests/config/k6_sa.yaml、k6_rolebinding.yaml、k6_sa_secret.yaml，并 clone grafana/k6-operator 仓库执行make deploy。对应的清理目标为delete-test-env-k6。

2.9 运行性能测试

全量运行：

make test-perf-all

只运行选中的测试，通过DAPR_PERF_TEST环境变量指定（空格分隔多个测试名）：

export DAPR_PERF_TEST="<app-name-1> <app-name-2>" make test-perf-all

<app-name>对应 tests/dapr_tests.mk 中的PERF_TESTS。例如只运行actor_id_scale与workflows：

export DAPR_PERF_TEST="actor_id_scale workflows" make test-perf-all

从 tests/dapr_tests.mk 的test-perf-all目标可以看到底层执行逻辑：check-e2e-env test-deps先校验环境变量并安装gotestsum（v1.13.0），随后以-timeout 2.5h -p 1 -count=1 -v -tags=perf ./tests/perf/...运行测试，同时设置NO_API_LOGGING=true、DAPR_TEST_NAMESPACE、DAPR_TEST_TAG、DAPR_TEST_REGISTRY、DAPR_TEST_MINIKUBE_IP等变量，产出 JSON 报告（$(TEST_OUTPUT_FILE_PREFIX)_perf.json）与 JUnit 报告，并通过jq -r .Output ... | strings提取测试输出；当DAPR_PERF_TEST非空时，则对每个测试名循环执行./tests/perf/<app>/...。每个单项测试也有独立目标test-perf-<name>（如make test-perf-service-invocation-http），同样由模板批量生成。

性能测试依赖上述所有前置步骤（运行时镜像、测试应用镜像、组件配置、第三方软件），也可用 tests/dapr_tests.mk 中的perf-build-deploy-run一键串起“初始化 + 构建部署 + 测试”。

2.10 生成性能图表

任何一次性能测试的gotestsumJSON 报告都可以离线渲染成图表——本地运行的test_report_perf*.json或 CI 产出的test_perf.json均可：

cd tests/perf/report go run . -input <path-to-report.json[.gz]> -version <output-folder>

报告生成器位于 tests/perf/report，核心实现为 charts.go。它支持以下命令行参数：

参数	说明
`-input`	gotestsum JSON 报告路径，`.gz`文件会自动解压（默认`./test_report_perf.json`）
`-version`	图表输出子目录名（默认`master`），按 Dapr 版本归类
`-infra`	运行环境的硬件描述，会写入生成的 README 顶部，便于跨环境对比（CI 传入 tests/test-infra/perf-infra-description.txt 中的 AKS 节点池描述）
`-manifest`	同时输出 docs 站点渲染用的 manifest JSON

图表生成逻辑（详见 tests/perf/report/charts/README.md）：

会把多次运行的同一逻辑测试（如TestWorkflowWithConstantVUs/[T_30_300]:_#01）按名称归一化聚合：多次运行会生成带_avg后缀的平均图表与跨运行延迟对比图（*_duration_comparison.png），单次运行则直接生成单套图表；
图表类型包括：时长分解（duration breakdown，含 min/med/avg/p90/p95/max 分位）、性能摘要（成功率与 VU 数）、吞吐量（收发 KB/s）、数据量（自动按 KB/MB/GB 缩放单位）、跨运行延迟对比（p50 与 p95）；
每个 API 的 README 顶部会生成“Throughput per resource”表：各场景的 iterations/sec 与 app/sidecar 的 CPU/内存消耗，以及每 CPU 核、每 GB 内存的派生吞吐——这是同一基础设施下横向对比场景与版本的效率核心指标；
仓库中的历史压缩报告存放在tests/perf/report/data/<version>/test_report_perf.json.gz（如data/v1.18.0/）。

Fortio 类测试的结果结构可参考 tests/perf/test_result.go 中的TestResult：包含请求 QPS（RequestedQPS/ActualQPS）、时长直方图（DurationHistogram，含各分位）、返回码分布（RetCodes）、报文大小（Sizes）等字段，是图表渲染与指标汇总的数据基础。

2.11 清理测试数据

测试完成后，建议清理旧的测试数据以便区分新一轮结果：

make test-clean

从 tests/dapr_tests.mk 的test-clean目标看，它会删除tests/e2e/*/dist、tests/perf/*/dist、tests/perf/*/test_report_summary_table_*.json以及仓库根目录下的test_report_*.json/test_report_*.xml。如需拆除 Kind 集群与本地 registry，可使用make delete-kind；删除 Minikube 用make delete-minikube。

三、通过 CI（GitHub Actions）运行性能测试

为了保持构建基础设施简单，Dapr 使用dapr-testGitHub Actions 工作流在 AKS 集群上运行 e2e 测试，另有独立工作流在 Kind 集群中运行 E2E：

贡献者创建 Pull Request 后，Kind 集群上的 E2E 测试会自动执行，以获得更快的反馈；
若要在AKS 集群上运行 E2E（及性能测试），需要由 maintainer 或 approver 在 PR 中回复评论/ok-to-perf来触发。

即：性能测试（perf）属于按需触发的高成本 CI 任务，不会随每个 PR 自动运行。

四、可选：可视化性能测试指标

性能测试过程中产生的指标可以通过 Prometheus Pushgateway 收集，再由 Grafana 展示为仪表盘。

4.1 启用指标推送

测试程序默认在未配置 Pushgateway 地址时跳过指标推送（见 tests/perf/utils/prometheus_metrics.go 中PushPrometheusMetrics的判空逻辑）。设置以下环境变量即可开启：

export DAPR_PERF_METRICS_PROMETHEUS_PUSHGATEWAY_URL="http://localhost:9091"

如果 Pushgateway 启用了基本认证，还可设置：

export DAPR_PERF_METRICS_PROMETHEUS_PUSHGATEWAY_USERNAME=<user> export DAPR_PERF_METRICS_PROMETHEUS_PUSHGATEWAY_PASSWORD=<password>

该工具会为每次性能测试推送以下指标（以 Gauge 形式，按perf_test分组、可按component进一步分组）：

指标名	含义
`BASELINE_RESPONSE_TIME`	基线测试平均响应时间（无 Dapr 参与）
`DAPR_RESPONSE_TIME`	Dapr 参与下的平均响应时间
`LATENCY_BY_DAPR`	Dapr sidecar 带来的附加延迟
`APP_CPU_USAGE`	应用 CPU 使用
`DAPR_SIDECAR_CPU_USAGE`	Dapr sidecar CPU 使用
`APP_MEMORY_USAGE`	应用内存使用
`DAPR_SIDECAR_MEMORY_USAGE`	Dapr sidecar 内存使用
`APPLICATION_THROUGHPUT`	实际吞吐（QPS）

4.2 在 Kubernetes 集群中安装监控组件

需要安装：Prometheus、Pushgateway、Grafana。

创建命名空间：

DAPR_PERF_METRICS_NAMESPACE=dapr-perf-metrics kubectl create namespace $DAPR_PERF_METRICS_NAMESPACE

安装 Prometheus Server：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install --namespace $DAPR_PERF_METRICS_NAMESPACE prometheus prometheus-community/prometheus

Pushgateway：上述 Prometheus 安装自带 pushgateway。将本地 9091 端口转发到prometheus-pushgatewayPod：

kubectl port-forward --namespace $DAPR_PERF_METRICS_NAMESPACE deployment/prometheus-prometheus-pushgateway 9091

之后即可在http://localhost:9091访问。

Grafana：创建grafana.yaml文件，内容如下（Deployment + Service，端口 80 → 3000）：

apiVersion: apps/v1 kind: Deployment metadata: name: grafana namespace: dapr-perf-metrics spec: replicas: 1 selector: matchLabels: app: grafana template: metadata: labels: app: grafana spec: containers: - name: grafana image: grafana/grafana:latest ports: - containerPort: 3000 --- apiVersion: v1 kind: Service metadata: name: grafana namespace: dapr-perf-metrics spec: type: LoadBalancer ports: - port: 80 targetPort: 3000 protocol: TCP selector: app: grafana

应用并转发端口：

kubectl apply -f grafana.yaml kubectl port-forward --namespace $DAPR_PERF_METRICS_NAMESPACE deployment/grafana 3000

4.3 配置 Grafana 数据源与仪表盘

浏览器访问http://localhost:3000，使用默认账号admin/admin登录；
进入Data Sources，添加 Prometheus 数据源；
HTTP URL 填写 Prometheus Server Pod 的 ClusterIP，可通过以下命令获取：

kubectl get svc --namespace $DAPR_PERF_METRICS_NAMESPACE

导入 Dapr 提供的性能测试仪表盘模板：tests/grafana/grafana-perf-test-dashboard.json。之后运行性能测试时，指标会由测试程序推送到 Pushgateway，Prometheus 抓取后即可在仪表盘中实时可视化。

4.4 仪表盘效果示例

下图为 Dapr 性能测试仪表盘的一个示例视图，按Application与Dapr Sidecar两组分别展示延迟（Latency）、吞吐（Throughput）、CPU 与内存使用趋势，方便直观对比应用自身与 Dapr sidecar 的资源消耗与性能表现：

五、小结

至此，一条完整的 Dapr 性能测试链路已经打通：

准备：make setup-kind创建 Kind 集群与本地 registry，kubectl create namespace dapr-tests，设置 registry/tag 与 Fortio 参数环境变量；
部署被测运行时：make build-linux docker-build docker-push docker-deploy-k8s setup-3rd-party，按需setup-app-configurations、setup-disable-mtls、DAPR_DISABLE_TELEMETRY=true；
准备测试环境：make setup-test-components、make build-perf-app-all push-perf-app-all，k6 测试额外执行make setup-test-env-k6；
执行与产出：make test-perf-all（可用DAPR_PERF_TEST挑选测试），用 tests/perf/report 的生成器从gotestsumJSON 报告渲染图表，最后make test-clean清理；
可视化：配置DAPR_PERF_METRICS_PROMETHEUS_PUSHGATEWAY_URL，部署 Prometheus/Pushgateway/Grafana，导入 tests/grafana/grafana-perf-test-dashboard.json 仪表盘。

本地流程与 CI 流程互为补充：CI 通过 GitHub Actions 在 Kind（自动）与 AKS（/ok-to-perf触发）上运行，而本地流程让开发者能在提交前针对自己的运行时改动快速获得延迟、吞吐与资源占用数据，是 Dapr 性能回归验证的关键手段。所有相关make目标与默认参数均可在 Makefile 与 tests/dapr_tests.mk 中溯源核对。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析