拓冰网站定制 
Redpanda Connect 组件基准测试指南从 Docker 环境搭建到 AWS 实测与持续监控【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect本文是 Redpanda Connect 开源仓库本项目为 Redpanda Connect 的镜像/衍生版本中 docs/benchmarking.md 的系统性展开。它完整描述了如何为任意 connector连接器搭建可复现的基准测试套件用 Docker 拉起外部依赖、生成接近真实的测试数据集、利用内置benchmarkprocessor 测量吞吐量并在 PR 中记录与汇报结果。读完本文你将掌握一套从「本地 Docker 单机基准」到「AWS 真实端点基准 长期 soak 浸泡测试 回归基线」的完整性能验证工作流并能够为仓库中的每个组件建立起可维护、可追溯的 benchmark 目录。基准测试的整体策略Redpanda Connect 的基准测试分为两个阶段对应两种截然不同的运行环境与目标第一阶段本地 Docker 基准。每个需要基准测试的 connector 在其实现包内拥有一个自包含的bench/目录例如internal/impl/component/bench/。该套件必须能够通过单条task命令完全复现并在接近真实的条件下测量连接器的吞吐量。第二阶段AWS 真实端点基准与 soak 浸泡测试。在专用的 AWS 基础设施上运行真实端点包括带 CloudWatch 告警的持续 soak 运行和滚动回归基线。这一阶段的所有细节集中在benchmarking/aws/README.md与benchmarking/aws/SOAK.md中。整个基准测试的通用方法遵循四个步骤在 Docker 中启动外部依赖数据库、消息代理等生成接近真实形态的数据集使用配置好连接器的 Redpanda Connect 运行管道利用内置的benchmarkprocessor 测量吞吐量在 PR 描述中记录结果msg/sec、MB/sec。AWS 阶段的测量结果会落入docs/benchmark-results/SUMMARY.md中由脚本自动维护的区段可通过task aws:summary重新生成。本地基准套件的目录结构基准测试文件统一放在internal/impl/component/bench/下。仓库中现有的套件包括internal/impl/mssqlserver/bench/、internal/impl/oracledb/bench/、internal/impl/aws/dynamodb/bench/、internal/impl/redpanda/migrator/bench/、internal/impl/postgresql/bench/、internal/impl/mysql/bench/、internal/impl/iceberg/bench/、internal/impl/salesforce/bench/等。推荐的文件组织如下internal/impl/component/bench/ ├── README.md # 运行方式、前置条件、预期输出 ├── Taskfile.yaml # Task runner 编排 ├── benchmark_config.yaml # Redpanda Connect 管道配置 ├── docker-compose.yml # 可选多服务部署 ├── create.sql # 可选建表脚本 ├── users.sql # 可选数据生成脚本 └── main.go # 可选程序化数据播种其中Taskfile.yaml是整套流程的「指挥中枢」benchmark_config.yaml是测量吞吐量的核心管道配置。第一步搭建外部依赖基准测试应使用与生产环境相同的镜像来运行本地服务——除非别无选择例如 DynamoDB Local否则应避免使用 lite 或 local 变体并在文档中说明这一限制。通过在Taskfile.yaml中定义任务来管理容器的启动、停止与日志version: 3 tasks: service:up: cmd: | docker run -d \ --name service-name \ -p host-port:container-port \ -e ENV_VARS \ image service:down: cmd: docker rm -fv service-name service:logs: cmd: docker logs -f service-name对于涉及多个服务例如源集群与目标集群的基准测试应改用docker-compose.yml。可复现性控制CPU、内存与 Go 运行时为了在不同运行之间获得一致的结果需要在 docker-compose 中钉住资源CPU 绑定cpuset——避免 OS 调度噪声。为每个容器分配专用核使它们互不争抢内存限制mem_limit——防止 OOM killer 介入并保持条件一致Go 运行时调优——在 Connect 容器上设置GOMAXPROCS与GOMEMLIMIT以控制 goroutine 调度与 GC 压力。迁移器migrator基准测试的 docker-compose 是一个把源、目标、loader 和 migrator 各自钉在不同 CPU 集合上的参考实现migrator: environment: GOMAXPROCS: 3 GOMEMLIMIT: 3GiB cpuset: 5,6,7 mem_limit: 3500M第二步生成测试数据数据集设计应使用多种不同 schema 的表例如 users、products、orders而不是单张巨大的表。这更接近真实场景并且对 CDC 连接器尤其重要——因为 per-table 并行度是吞吐量的关键因素。行大小也应贴近真实1-2KB 是典型值。根据连接器类型有三种数据生成方式SQL 脚本方式适用于数据库连接器。使用带循环的存储过程生成大批量数据-- Example: generate 500,000 rows DECLARE i INT 0; WHILE i 500000 BEGIN INSERT INTO users (name, email, created_at) VALUES (CONCAT(user-, i), CONCAT(user, i, example.com), GETDATE()); SET i i 1; END每个数据生成脚本都应在 Taskfile 中登记为任务data:users: cmd: task sqlcmd EXTRA_ARGS-i users.sqlGo 播种程序方式对于拥有原生 Go SDK 的服务如 DynamoDB编写一个main.go使用并发 worker 播种数据并借助BatchWriteItem之类的批量 API 提升速度。DynamoDB 基准internal/impl/aws/dynamodb/bench/main.go就是参考实现——它用 16 个并发 worker 插入了 45 万个条目。Bloblanggenerateinput 方式对于只关心原始消息吞吐量的基准例如 migrator 基准直接使用带generateinput 的 Redpanda Connect 配置input: generate: interval: # As fast as possible count: 30_000_000 batch_size: 1_000 mapping: | root your payload hereinterval: 表示以最快速度生成migrator 基准中的流式 loaderinternal/impl/redpanda/migrator/bench/loader-streaming.yaml就采用这种模式可持续产生约 100MB/s 的负载适合长时间 profiling 会话。第三步配置基准测试管道创建benchmark_config.yaml——一个从被测连接器读取数据、并将输出丢弃sink 到drop: {}的 Redpanda Connect 配置。其核心元素是benchmarkprocessor它按设定间隔记录滚动吞吐量统计。仓库中 SQL Server CDC 基准的实际配置如下http: debug_endpoints: true # Required for profiling input: microsoft_sql_server_cdc: connection_string: sqlserver://sa:YourStrong!Passw0rdlocalhost:1433?databasetestdbencryptdisable stream_snapshot: false include: - dbo.users - dbo.products - dbo.cart batching: count: 1000 output: processors: - benchmark: interval: 1s count_bytes: true # Report MB/sec in addition to msg/sec drop: {} # Discard output — we only care about read throughput logger: level: INFO metrics: prometheus: add_process_metrics: true add_go_metrics: trueDynamoDB CDC 基准的配置则展示了另一种形态——通过aws_dynamodb_cdcinput 监听 3 张表、使用checkpoint_table保存游标、并指向本地 DynamoDB Local 的endpoint: http://localhost:8000。关键配置点http.debug_endpoints: true——在localhost:4195暴露 pprof 端点用于 CPU/内存/阻塞 profilingbenchmarkprocessor——按配置的interval记录msg/sec与bytes/secdrop: {}——消除输出开销使测量结果只反映输入吞吐量Prometheus metrics——开启进程与 Go 运行时指标便于通过 Grafana 监控。批大小调优batching.count参数对吞吐量影响显著且不同连接器的差异很大。现有基准的取值范围从 1,000SQL Server、DynamoDB到 140,000Oracle CDC见docs/benchmark-results/oracledb-cdc.md中的batching.count: 140000。批太小意味着过高的 per-batch 开销批太大则带来内存压力与延迟尖峰。应在文档中记录测试过的取值与最优结果。Docker 镜像架构在 Apple SiliconARM上务必使用正确的镜像架构。migrator 基准显式使用redpandata/connect:edge-arm64。在 Rosetta/QEMU 模拟下运行 x86 镜像会使吞吐量骤降产生误导性结果。第四步运行基准测试将整个流程串进 Taskfile使task或task run执行完整序列run: cmds: - task: service:up - task: create - task: seed - go run ../../../../../cmd/redpanda-connect/main.go run ./benchmark_config.yaml也可以手动分步执行# Start the service task service:up # Create schema and seed data task create task seed # Run the benchmark go run ../../../../cmd/redpanda-connect/main.go run ./benchmark_config.yaml运行后应当看到滚动吞吐量日志INFO rolling stats: 101000 msg/sec, 135 MB/sec serviceredpanda-connect ... INFO rolling stats: 104000 msg/sec, 139 MB/sec serviceredpanda-connect ...注意cmd/redpanda-connect/main.go是仓库的入口程序go run可直接从工作树构建并运行无需预先安装二进制。第五步运行之间重置状态大多数 CDC 连接器会维护检查点/游标。需要在两次运行之间清除它drop-checkpoint: cmd: command to drop checkpoint table/cacheDynamoDB 基准配置中的checkpoint_table: bench-checkpoints正是这类状态存储若不清理第二次运行将从上次断点继续而非重新读取全量数据。第六步编写 README每个bench/目录必须有README.md包含前置条件——需要安装的工具例如brew install sqlcmd、Docker 等如何运行——分步命令预期输出——示例吞吐量日志让评审者知道「正常」长什么样注意事项——任何局限例如单分片限制、容器资源约束、数据保留窗口。快照模式 vs 流式模式对 CDC 连接器两种模式必须分别基准测试它们的性能特征截然不同快照模式Snapshot——读取表的完整当前状态。受益于更高的读并发通常能达到更高吞吐由于本质上是一次批量SELECT在各种 SQL 连接器之间表现相似。Oracle CDC 快照模式约达 140K msg/sec而流式只有约 50K详见docs/benchmark-results/oracledb-cdc.md流式模式Streaming——从日志读取变更事件CDC 表、LogMiner、DynamoDB Streams 等。通常每个表单线程并受源系统变更捕获机制约束。这才是生产负载真正关心的模式。两个数字都要报告快照吞吐量确立上限流式吞吐量是客户实际体验到的。数据保留与时机部分源系统对变更数据设有保留窗口DynamoDB Streams——24 小时保留。插入数据后要及时运行基准测试Oracle LogMiner——SCN 窗口与 redo 日志保留。需要按 Oracle 基准中的rman_setup.rman适当配置 RMAN 归档日志策略SQL Server CDC——清理作业可能清除变更表。基准测试期间应禁用或延长保留期。将这些保留约束写进基准 README避免他人把「0 msg/sec」误判为 bug 而浪费时间。Profiling 深入分析仓库在resources/docker/profiling/提供了配套的 profiling 工具栈Prometheus Grafana# Start Prometheus Grafana monitoring stack cd resources/docker/profiling task up # Grafana: http://localhost:3000 # Prometheus: http://localhost:9090 # Capture profiles (requires debug_endpoints: true in your config) task profile:cpu # 30s CPU profile task profile:mem # Memory heap profile task profile:block # Goroutine blocking profile # View profiles in browser task pprof:cpu task pprof:mem task pprof:block汇报结果基准结果应记录在PR 描述中包括运行环境——笔记本/VM 规格、OS、Docker 资源限制数据集——行数、近似大小例如 1.4KB × 21M rows 24GB吞吐量——展示 msg/sec 与 MB/sec 的滚动统计输出Profiling 产物——Grafana 面板截图、Go 运行时指标、内存 profile观察——瓶颈分析、为提升性能尝试过的方法、必要时与其他工具的对比。瓶颈分析方法论优秀的基准 PR 不只报告数字还会定位瓶颈所在。过往基准使用过的技巧绕过连接器——用sql_rawinput 或更简单的 input排除连接器自身代码与源系统之间的瓶颈归属SQL Server CDC 基准曾这样做检查连接利用率——记录sql.DBStats查看实际在用的连接数。SQL Server 基准发现 100 个连接中只有 1 个活跃证明瓶颈是单线程读取而非 Connect 本身变换环境——对比本地 Docker、原生安装与云托管实例如 Azure SQL Premium隔离容器化开销的影响跨表并行——若源端按表单连接受限用多张表测试吞吐量是否随连接数线性扩展与竞品对比——用 Debezium 或同类工具快速跑一次判断吞吐上限是协议固有的如 Oracle LogMiner还是 Connect 实现特有的。Oracle 基准中的benchmark_config_debezium.yaml与docker-compose.debezium.yaml正是为此准备的——对比结果同为约 50K msg/sec确认了这是 LogMiner 协议限制而非 Connect 限制。将结果持久化到文件为了事后分析可以把基准输出写入文件而非或同时丢弃output: processors: - benchmark: interval: 1s count_bytes: true file: path: ./results.json codec: lines记录结果除 PR 描述外还要在docs/benchmark-results/中新增或更新结果文件。每个连接器一个文件例如mssqlserver-cdc.md新运行以带日期的区段追加以便跟踪性能随时间的变化。新结果应包含日期与 PR 链接、环境细节硬件、Docker 配置、资源限制、数据集描述行数、行大小、总大小、配置要点批大小、并行度、调优参数、吞吐量表与原始日志输出、观察与瓶颈分析。SQL Server CDC 基准 PR 的示例Runtime: ~4m 30s Dataset: 1.4kb × 21,198,489 rows 24.1GBINFO rolling stats: 101000 msg/sec, 135 MB/sec INFO rolling stats: 104000 msg/sec, 139 MB/sec INFO rolling stats: 103000 msg/sec, 138 MB/sec现有基准一览仓库目前记录的基准结果如下完整表见docs/benchmark-results/SUMMARY.md非技术概述适合销售与市场等读者ComponentBench SuiteResultsThroughputNotesRedpanda Migratorinternal/impl/redpanda/migrator/bench/results1 GB/s, 1M msg/secCluster-to-cluster, 30GB transferSQL Server CDCinternal/impl/mssqlserver/bench/results~135 MB/sec, 100K msg/secSingle connection bottleneckOracle CDCinternal/impl/oracledb/bench/results~50K msg/sec (streaming)LogMiner single-threaded limitationDynamoDB CDCinternal/impl/aws/dynamodb/bench/results~200 MB/sec, 100K msg/secDynamoDB Local, 3 tables x 150K items这些数字代表读吞吐量——Redpanda Connect 从各源摄取数据的速度写入目标系统的吞吐取决于目标本身需单独基准测试。保持结果更新基准结果会过时遵循以下实践保持其新鲜新增基准套件时——在docs/benchmark-results/创建对应结果文件更新本文的表格与docs/benchmark-results/SUMMARY.md修改连接器性能路径时——重新运行基准并向结果文件追加带日期的新区段。这包括批处理、缓冲、连接处理、序列化以及任何处于热路径的代码变更重跑既有基准时——总是追加而非覆盖以便跟踪性能变化。包含日期、PR 链接以及自上次运行以来的变更代码评审时——/review技能包含基准检查它会标记新增/修改bench/目录而未更新结果文件的 PR以及描述中写了吞吐量数字却未记录到docs/benchmark-results/的 PR也会提示性能关键型连接器变更可能需要重跑基准。Go Benchmark 测试单元级对于内部组件序列化、转换等的单元级基准使用标准 Gotesting.B基准放在*_test.go文件中。用b.ReportMetric()上报领域特定指标例如 spans/sec用b.ReportAllocs()跟踪分配func BenchmarkConvert(b *testing.B) { // setup... b.ReportAllocs() for b.Loop() { // operation under test } b.ReportMetric(float64(itemCount)/b.Elapsed().Seconds(), items/sec) }这类基准与上述集成级基准互补适合隔离特定代码路径的性能。第二阶段AWS 真实端点基准与 Soak 浸泡测试本地 Docker 路径只是第一阶段。第二阶段在专用 AWS 基础设施上针对真实端点运行包括带 CloudWatch 告警的持续 soak 浸泡测试和滚动回归基线。完整运行手册见benchmarking/aws/README.md与benchmarking/aws/SOAK.md。一次 AWS 运行做了什么一条命令即可把一个场景 YAML 转化为完整流程通过 Terraform 构建 AWS 环境——VPC、runner EC2、load-gen EC2、3-broker Redpanda 集群、源数据库RDS Postgres、结果存储桶从你的工作树构建redpanda-connect二进制并暂存到 runner 主机/soakA/B 对比时可用--binary指定预构建二进制生成种子数据集并对真实源施加持续写负载经过真实复制路径此处为逻辑复制捕获测量broker 侧吞吐量ground truth、Connect 自身的滚动统计、/metrics抓取goroutines、RSS、GCsoak 运行还按分钟向 CloudWatch 发射指标并生成派生 backlog 序列结果本地输出 JSON markdownsoak 运行则持久归档到redpanda-connect-bench-soak-archive存储桶并写入 soak-index自动 teardown孤儿回收 Lambda 作为兜底。两种运行档案共享全部基础设施Benchbenchmarking/aws/scenarios/postgres/orders-cdc.yaml短时、最大负载的 CPU 扫描用于寻找吞吐上限Soakorders-soak.yaml、orders-soak-pr.yamlsoak: true长时、中等负载约为上限的 10-15%的耐力测试用于捕获内存泄漏、静默停顿与凭证轮换 bug。调度与 PR 触发.github/workflows/soak_nightly.yml——每晚 08:10 UTCcron 在默认分支上激活变更门控自上次 soak 提交以来无相关合并则跳过手动 dispatch 总是运行.github/workflows/soak_pr.yml——在 PR 上评论/soak需写权限在相同基础设施上做 base-vs-PR 对比并以置顶评论形式回帖。两者都通过 GitHub OIDC 认证不存密钥企业 license 从 Secrets Manager 获取。从笔记本运行# one-time (per account): persistent stack (dashboards, alarms, reaper, # OIDC, archive bucket) license secret — see SOAK.md cd benchmarking/aws task aws:persistent # builds cleanup-lambda/bootstrap.zip itself # validate a scenario (no AWS spend) task aws:validate scenariopostgres/orders-cdc # run a bench (~25 min infra sweep; ~$2-3) aws-vault exec profile -- env REDPANDA_LICENSE_FILEPATHpath \ task aws:bench scenariopostgres/orders-cdc # tear down after a failed/kept run task aws:down scenariopostgres/orders-cdcbenchmarking/aws/Taskfile.yml中定义的aws:validate、aws:bench、aws:down、aws:persistent、aws:cost-check、aws:summary等任务共同构成了这套命令行接口其中 runner 位于独立的 Go 模块benchmarking/aws/runner/因此构建后再在仓库根运行。运营铁律每条都源于真实事故细节见 SOAK.md同一时刻只跑一个 bench——所有会话共享同一份 Terraform state 与 stackrunner 的 pre-flight 在 bench EC2 存在时拒绝启动凭证必须比运行更长寿——aws-vault exec静态凭证约 1 小时失效优先使用 workflow 或 SSO 会话 profileCtrl-C 只能按一次——重复中断会在 destroy 中途杀掉 deferred teardown日志行不等于 teardown 证据——用 EC2/RDS 查询验证workflow 会自动完成若可能在 teardown 前切换分支请从 git worktree 运行。孤儿清理benchmarking/aws/cleanup-lambda/由 persistent stack 部署每 15 分钟运行销毁任何超过 4 小时的Projectredpanda-connect-bench资源。它刻意位于会话 stack之外——安全网不能与它所守护的对象共享生命周期。合法运行超过 4 小时需先禁用规则aws events disable-rule --name redpanda-connect-bench-orphan-cleanup结束后重新启用。Soak 测试的运行手册Soak 运行让一个连接器配置在持续中等负载下运行 90 分钟每晚一次让只有在运行期才会显现的 bug 类别——缓慢泄漏、静默停顿、轮换窗口、增长中的 lag——在客户发现之前暴露出来。各组成部分的分工如下表PieceWhereJobSoak scenariobenchmarking/aws/scenarios/engine/*-soak.yamlsoak: true持续负载档案验证到 1 cpu_point仅 connectRunner soak modebenchmarking/aws/runner/main.go、matrix.go、cloudwatch.go缩放节奏、10 分钟 S3 检查点、按分钟 CloudWatch 发射、backlog 序列Dashboards alarmsbenchmarking/aws/terraform/persistent/main.tf的soak_scenarios变量、alarms.tf每个场景一个 dashboard 三个告警stall / rss-slope / backlog→ SNSredpanda-connect-bench-soak-alertsArchive baselineredpanda-connect-bench-soak-archive存储桶每次运行的 result.json 原始产物soak-index/供滚动基线比较器使用不足 3 次运行仅建议此后吞吐 85% / RSS 130% 基线即判定失败Nightly workflow.github/workflows/soak_nightly.yml08:10 UTC cron 遍历轮换矩阵postgres、mysql串行、仅从默认分支取 arms 手动 dispatchOIDC 凭证4hlicense 来自 Secrets Managerteardown 对照 AWS 验证PR comparison.github/workflows/soak_pr.yml/soak评论写权限门控→ base-vs-PR 二进制、相同基础设施、置顶对比评论将新连接器加入轮换的步骤先跑或找到标准 bench 扫描确定其上限soak 速率应约为实测上限的 10-15%——soak 测试的是「长期正确性」而非吞吐量复制benchmarking/aws/scenarios/postgres/orders-soak.yaml并调整连接器/stack/管道/速率保持实例小巧postgres soak 用 db.r6g.xlarge c8g.xlarge。注意引擎特定的下限例如 RDS gp3 在 400GB 以下禁止配置 provisioned IOPS/吞吐。task aws:validate scenarioengine/name必须通过在benchmarking/aws/terraform/persistent/variables.tf的soak_scenarios中注册 dashboard 告警然后task aws:persistent——必须在轮换条目合并之前应用因为 cron 在 workflow 落到默认分支的瞬间就会武装自己将场景路径追加到soak_nightly.yml的 schedule 列表矩阵串行max-parallel: 1且fail-fast: false即使其他条目红也会继续 soak首次运行手动 dispatch nightly workflow 并输入场景名。基线比较器在存在三个 soak-index 条目之前保持建议状态可选添加 PR 变体*-soak-pr.yaml——相同场景、30 分钟时长、arms: [{id: base, binary: base}, {id: pr, binary: pr}]场景名必须与 nightly 的不同使其指标落在告警维度之外。告警渠道soak 期间的告警是急性渠道红色 nightly workflow 是构建间渠道/soak评论是合并前渠道。benchmarking/aws/grafana/soak-dashboard.json是一个可导入的 Grafana 面板覆盖相同的 CloudWatch 指标带连接器/场景的下拉、告警阈值与 CloudWatch 告警注解。已知限制详见 SOAK.md组织级ci-cloud-nuke每晚约 02:25 UTC 清扫该账户已多次删除 tfstate 锁表故后端改用 S3 原生use_lockfile锁、每晚解除孤儿回收器的调度规则并删除 stall backlog 告警——豁免手段是cloud-nuke-excluded true标签postgres_cdc 的 IAM 认证无法用于 vanilla RDS复制协议连接拒绝 IAM 令牌因此 postgres soak 无法覆盖凭证轮换窗口该职责由 mysql soak 承担GitHub 会在公共仓库 60 天无活动后禁用 cron workflow。成本控制一次 postgres bench 运行约 $2-3一次 nightly soak 约 $5变更门控跳过的日子为 $0。最坏情况的 stranded-stack 由回收器的 4 小时 TTL 兜底。task aws:cost-check可通过 AWS Cost Explorer 直接查看当日/7 天/本月支出。结语从internal/impl/component/bench/的自包含本地套件到benchmarking/aws/的生产级 AWS 基准与 soak 浸泡框架Redpanda Connect 的基准测试体系覆盖了「开发期验证」到「上线前持续回归」的完整链路。其核心方法论可概括为真实依赖生产镜像而非 lite 变体、真实数据多 schema、贴近实际行大小、可复现环境CPU 钉扎 内存限制 Go 运行时调优、隔离测量drop: {}benchmarkprocessor、以及透明的汇报机制PR 描述 docs/benchmark-results/结果文件 滚动基线。遵循这套流程任何连接器性能变更都可以在合并前被客观量化与回归把关。【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Redpanda Connect 组件基准测试指南：从 Docker 环境搭建到 AWS 实测与持续监控
Redpanda Connect 组件基准测试指南从 Docker 环境搭建到 AWS 实测与持续监控【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect本文是 Redpanda Connect 开源仓库本项目为 Redpanda Connect 的镜像/衍生版本中 docs/benchmarking.md 的系统性展开。它完整描述了如何为任意 connector连接器搭建可复现的基准测试套件用 Docker 拉起外部依赖、生成接近真实的测试数据集、利用内置benchmarkprocessor 测量吞吐量并在 PR 中记录与汇报结果。读完本文你将掌握一套从「本地 Docker 单机基准」到「AWS 真实端点基准 长期 soak 浸泡测试 回归基线」的完整性能验证工作流并能够为仓库中的每个组件建立起可维护、可追溯的 benchmark 目录。基准测试的整体策略Redpanda Connect 的基准测试分为两个阶段对应两种截然不同的运行环境与目标第一阶段本地 Docker 基准。每个需要基准测试的 connector 在其实现包内拥有一个自包含的bench/目录例如internal/impl/component/bench/。该套件必须能够通过单条task命令完全复现并在接近真实的条件下测量连接器的吞吐量。第二阶段AWS 真实端点基准与 soak 浸泡测试。在专用的 AWS 基础设施上运行真实端点包括带 CloudWatch 告警的持续 soak 运行和滚动回归基线。这一阶段的所有细节集中在benchmarking/aws/README.md与benchmarking/aws/SOAK.md中。整个基准测试的通用方法遵循四个步骤在 Docker 中启动外部依赖数据库、消息代理等生成接近真实形态的数据集使用配置好连接器的 Redpanda Connect 运行管道利用内置的benchmarkprocessor 测量吞吐量在 PR 描述中记录结果msg/sec、MB/sec。AWS 阶段的测量结果会落入docs/benchmark-results/SUMMARY.md中由脚本自动维护的区段可通过task aws:summary重新生成。本地基准套件的目录结构基准测试文件统一放在internal/impl/component/bench/下。仓库中现有的套件包括internal/impl/mssqlserver/bench/、internal/impl/oracledb/bench/、internal/impl/aws/dynamodb/bench/、internal/impl/redpanda/migrator/bench/、internal/impl/postgresql/bench/、internal/impl/mysql/bench/、internal/impl/iceberg/bench/、internal/impl/salesforce/bench/等。推荐的文件组织如下internal/impl/component/bench/ ├── README.md # 运行方式、前置条件、预期输出 ├── Taskfile.yaml # Task runner 编排 ├── benchmark_config.yaml # Redpanda Connect 管道配置 ├── docker-compose.yml # 可选多服务部署 ├── create.sql # 可选建表脚本 ├── users.sql # 可选数据生成脚本 └── main.go # 可选程序化数据播种其中Taskfile.yaml是整套流程的「指挥中枢」benchmark_config.yaml是测量吞吐量的核心管道配置。第一步搭建外部依赖基准测试应使用与生产环境相同的镜像来运行本地服务——除非别无选择例如 DynamoDB Local否则应避免使用 lite 或 local 变体并在文档中说明这一限制。通过在Taskfile.yaml中定义任务来管理容器的启动、停止与日志version: 3 tasks: service:up: cmd: | docker run -d \ --name service-name \ -p host-port:container-port \ -e ENV_VARS \ image service:down: cmd: docker rm -fv service-name service:logs: cmd: docker logs -f service-name对于涉及多个服务例如源集群与目标集群的基准测试应改用docker-compose.yml。可复现性控制CPU、内存与 Go 运行时为了在不同运行之间获得一致的结果需要在 docker-compose 中钉住资源CPU 绑定cpuset——避免 OS 调度噪声。为每个容器分配专用核使它们互不争抢内存限制mem_limit——防止 OOM killer 介入并保持条件一致Go 运行时调优——在 Connect 容器上设置GOMAXPROCS与GOMEMLIMIT以控制 goroutine 调度与 GC 压力。迁移器migrator基准测试的 docker-compose 是一个把源、目标、loader 和 migrator 各自钉在不同 CPU 集合上的参考实现migrator: environment: GOMAXPROCS: 3 GOMEMLIMIT: 3GiB cpuset: 5,6,7 mem_limit: 3500M第二步生成测试数据数据集设计应使用多种不同 schema 的表例如 users、products、orders而不是单张巨大的表。这更接近真实场景并且对 CDC 连接器尤其重要——因为 per-table 并行度是吞吐量的关键因素。行大小也应贴近真实1-2KB 是典型值。根据连接器类型有三种数据生成方式SQL 脚本方式适用于数据库连接器。使用带循环的存储过程生成大批量数据-- Example: generate 500,000 rows DECLARE i INT 0; WHILE i 500000 BEGIN INSERT INTO users (name, email, created_at) VALUES (CONCAT(user-, i), CONCAT(user, i, example.com), GETDATE()); SET i i 1; END每个数据生成脚本都应在 Taskfile 中登记为任务data:users: cmd: task sqlcmd EXTRA_ARGS-i users.sqlGo 播种程序方式对于拥有原生 Go SDK 的服务如 DynamoDB编写一个main.go使用并发 worker 播种数据并借助BatchWriteItem之类的批量 API 提升速度。DynamoDB 基准internal/impl/aws/dynamodb/bench/main.go就是参考实现——它用 16 个并发 worker 插入了 45 万个条目。Bloblanggenerateinput 方式对于只关心原始消息吞吐量的基准例如 migrator 基准直接使用带generateinput 的 Redpanda Connect 配置input: generate: interval: # As fast as possible count: 30_000_000 batch_size: 1_000 mapping: | root your payload hereinterval: 表示以最快速度生成migrator 基准中的流式 loaderinternal/impl/redpanda/migrator/bench/loader-streaming.yaml就采用这种模式可持续产生约 100MB/s 的负载适合长时间 profiling 会话。第三步配置基准测试管道创建benchmark_config.yaml——一个从被测连接器读取数据、并将输出丢弃sink 到drop: {}的 Redpanda Connect 配置。其核心元素是benchmarkprocessor它按设定间隔记录滚动吞吐量统计。仓库中 SQL Server CDC 基准的实际配置如下http: debug_endpoints: true # Required for profiling input: microsoft_sql_server_cdc: connection_string: sqlserver://sa:YourStrong!Passw0rdlocalhost:1433?databasetestdbencryptdisable stream_snapshot: false include: - dbo.users - dbo.products - dbo.cart batching: count: 1000 output: processors: - benchmark: interval: 1s count_bytes: true # Report MB/sec in addition to msg/sec drop: {} # Discard output — we only care about read throughput logger: level: INFO metrics: prometheus: add_process_metrics: true add_go_metrics: trueDynamoDB CDC 基准的配置则展示了另一种形态——通过aws_dynamodb_cdcinput 监听 3 张表、使用checkpoint_table保存游标、并指向本地 DynamoDB Local 的endpoint: http://localhost:8000。关键配置点http.debug_endpoints: true——在localhost:4195暴露 pprof 端点用于 CPU/内存/阻塞 profilingbenchmarkprocessor——按配置的interval记录msg/sec与bytes/secdrop: {}——消除输出开销使测量结果只反映输入吞吐量Prometheus metrics——开启进程与 Go 运行时指标便于通过 Grafana 监控。批大小调优batching.count参数对吞吐量影响显著且不同连接器的差异很大。现有基准的取值范围从 1,000SQL Server、DynamoDB到 140,000Oracle CDC见docs/benchmark-results/oracledb-cdc.md中的batching.count: 140000。批太小意味着过高的 per-batch 开销批太大则带来内存压力与延迟尖峰。应在文档中记录测试过的取值与最优结果。Docker 镜像架构在 Apple SiliconARM上务必使用正确的镜像架构。migrator 基准显式使用redpandata/connect:edge-arm64。在 Rosetta/QEMU 模拟下运行 x86 镜像会使吞吐量骤降产生误导性结果。第四步运行基准测试将整个流程串进 Taskfile使task或task run执行完整序列run: cmds: - task: service:up - task: create - task: seed - go run ../../../../../cmd/redpanda-connect/main.go run ./benchmark_config.yaml也可以手动分步执行# Start the service task service:up # Create schema and seed data task create task seed # Run the benchmark go run ../../../../cmd/redpanda-connect/main.go run ./benchmark_config.yaml运行后应当看到滚动吞吐量日志INFO rolling stats: 101000 msg/sec, 135 MB/sec serviceredpanda-connect ... INFO rolling stats: 104000 msg/sec, 139 MB/sec serviceredpanda-connect ...注意cmd/redpanda-connect/main.go是仓库的入口程序go run可直接从工作树构建并运行无需预先安装二进制。第五步运行之间重置状态大多数 CDC 连接器会维护检查点/游标。需要在两次运行之间清除它drop-checkpoint: cmd: command to drop checkpoint table/cacheDynamoDB 基准配置中的checkpoint_table: bench-checkpoints正是这类状态存储若不清理第二次运行将从上次断点继续而非重新读取全量数据。第六步编写 README每个bench/目录必须有README.md包含前置条件——需要安装的工具例如brew install sqlcmd、Docker 等如何运行——分步命令预期输出——示例吞吐量日志让评审者知道「正常」长什么样注意事项——任何局限例如单分片限制、容器资源约束、数据保留窗口。快照模式 vs 流式模式对 CDC 连接器两种模式必须分别基准测试它们的性能特征截然不同快照模式Snapshot——读取表的完整当前状态。受益于更高的读并发通常能达到更高吞吐由于本质上是一次批量SELECT在各种 SQL 连接器之间表现相似。Oracle CDC 快照模式约达 140K msg/sec而流式只有约 50K详见docs/benchmark-results/oracledb-cdc.md流式模式Streaming——从日志读取变更事件CDC 表、LogMiner、DynamoDB Streams 等。通常每个表单线程并受源系统变更捕获机制约束。这才是生产负载真正关心的模式。两个数字都要报告快照吞吐量确立上限流式吞吐量是客户实际体验到的。数据保留与时机部分源系统对变更数据设有保留窗口DynamoDB Streams——24 小时保留。插入数据后要及时运行基准测试Oracle LogMiner——SCN 窗口与 redo 日志保留。需要按 Oracle 基准中的rman_setup.rman适当配置 RMAN 归档日志策略SQL Server CDC——清理作业可能清除变更表。基准测试期间应禁用或延长保留期。将这些保留约束写进基准 README避免他人把「0 msg/sec」误判为 bug 而浪费时间。Profiling 深入分析仓库在resources/docker/profiling/提供了配套的 profiling 工具栈Prometheus Grafana# Start Prometheus Grafana monitoring stack cd resources/docker/profiling task up # Grafana: http://localhost:3000 # Prometheus: http://localhost:9090 # Capture profiles (requires debug_endpoints: true in your config) task profile:cpu # 30s CPU profile task profile:mem # Memory heap profile task profile:block # Goroutine blocking profile # View profiles in browser task pprof:cpu task pprof:mem task pprof:block汇报结果基准结果应记录在PR 描述中包括运行环境——笔记本/VM 规格、OS、Docker 资源限制数据集——行数、近似大小例如 1.4KB × 21M rows 24GB吞吐量——展示 msg/sec 与 MB/sec 的滚动统计输出Profiling 产物——Grafana 面板截图、Go 运行时指标、内存 profile观察——瓶颈分析、为提升性能尝试过的方法、必要时与其他工具的对比。瓶颈分析方法论优秀的基准 PR 不只报告数字还会定位瓶颈所在。过往基准使用过的技巧绕过连接器——用sql_rawinput 或更简单的 input排除连接器自身代码与源系统之间的瓶颈归属SQL Server CDC 基准曾这样做检查连接利用率——记录sql.DBStats查看实际在用的连接数。SQL Server 基准发现 100 个连接中只有 1 个活跃证明瓶颈是单线程读取而非 Connect 本身变换环境——对比本地 Docker、原生安装与云托管实例如 Azure SQL Premium隔离容器化开销的影响跨表并行——若源端按表单连接受限用多张表测试吞吐量是否随连接数线性扩展与竞品对比——用 Debezium 或同类工具快速跑一次判断吞吐上限是协议固有的如 Oracle LogMiner还是 Connect 实现特有的。Oracle 基准中的benchmark_config_debezium.yaml与docker-compose.debezium.yaml正是为此准备的——对比结果同为约 50K msg/sec确认了这是 LogMiner 协议限制而非 Connect 限制。将结果持久化到文件为了事后分析可以把基准输出写入文件而非或同时丢弃output: processors: - benchmark: interval: 1s count_bytes: true file: path: ./results.json codec: lines记录结果除 PR 描述外还要在docs/benchmark-results/中新增或更新结果文件。每个连接器一个文件例如mssqlserver-cdc.md新运行以带日期的区段追加以便跟踪性能随时间的变化。新结果应包含日期与 PR 链接、环境细节硬件、Docker 配置、资源限制、数据集描述行数、行大小、总大小、配置要点批大小、并行度、调优参数、吞吐量表与原始日志输出、观察与瓶颈分析。SQL Server CDC 基准 PR 的示例Runtime: ~4m 30s Dataset: 1.4kb × 21,198,489 rows 24.1GBINFO rolling stats: 101000 msg/sec, 135 MB/sec INFO rolling stats: 104000 msg/sec, 139 MB/sec INFO rolling stats: 103000 msg/sec, 138 MB/sec现有基准一览仓库目前记录的基准结果如下完整表见docs/benchmark-results/SUMMARY.md非技术概述适合销售与市场等读者ComponentBench SuiteResultsThroughputNotesRedpanda Migratorinternal/impl/redpanda/migrator/bench/results1 GB/s, 1M msg/secCluster-to-cluster, 30GB transferSQL Server CDCinternal/impl/mssqlserver/bench/results~135 MB/sec, 100K msg/secSingle connection bottleneckOracle CDCinternal/impl/oracledb/bench/results~50K msg/sec (streaming)LogMiner single-threaded limitationDynamoDB CDCinternal/impl/aws/dynamodb/bench/results~200 MB/sec, 100K msg/secDynamoDB Local, 3 tables x 150K items这些数字代表读吞吐量——Redpanda Connect 从各源摄取数据的速度写入目标系统的吞吐取决于目标本身需单独基准测试。保持结果更新基准结果会过时遵循以下实践保持其新鲜新增基准套件时——在docs/benchmark-results/创建对应结果文件更新本文的表格与docs/benchmark-results/SUMMARY.md修改连接器性能路径时——重新运行基准并向结果文件追加带日期的新区段。这包括批处理、缓冲、连接处理、序列化以及任何处于热路径的代码变更重跑既有基准时——总是追加而非覆盖以便跟踪性能变化。包含日期、PR 链接以及自上次运行以来的变更代码评审时——/review技能包含基准检查它会标记新增/修改bench/目录而未更新结果文件的 PR以及描述中写了吞吐量数字却未记录到docs/benchmark-results/的 PR也会提示性能关键型连接器变更可能需要重跑基准。Go Benchmark 测试单元级对于内部组件序列化、转换等的单元级基准使用标准 Gotesting.B基准放在*_test.go文件中。用b.ReportMetric()上报领域特定指标例如 spans/sec用b.ReportAllocs()跟踪分配func BenchmarkConvert(b *testing.B) { // setup... b.ReportAllocs() for b.Loop() { // operation under test } b.ReportMetric(float64(itemCount)/b.Elapsed().Seconds(), items/sec) }这类基准与上述集成级基准互补适合隔离特定代码路径的性能。第二阶段AWS 真实端点基准与 Soak 浸泡测试本地 Docker 路径只是第一阶段。第二阶段在专用 AWS 基础设施上针对真实端点运行包括带 CloudWatch 告警的持续 soak 浸泡测试和滚动回归基线。完整运行手册见benchmarking/aws/README.md与benchmarking/aws/SOAK.md。一次 AWS 运行做了什么一条命令即可把一个场景 YAML 转化为完整流程通过 Terraform 构建 AWS 环境——VPC、runner EC2、load-gen EC2、3-broker Redpanda 集群、源数据库RDS Postgres、结果存储桶从你的工作树构建redpanda-connect二进制并暂存到 runner 主机/soakA/B 对比时可用--binary指定预构建二进制生成种子数据集并对真实源施加持续写负载经过真实复制路径此处为逻辑复制捕获测量broker 侧吞吐量ground truth、Connect 自身的滚动统计、/metrics抓取goroutines、RSS、GCsoak 运行还按分钟向 CloudWatch 发射指标并生成派生 backlog 序列结果本地输出 JSON markdownsoak 运行则持久归档到redpanda-connect-bench-soak-archive存储桶并写入 soak-index自动 teardown孤儿回收 Lambda 作为兜底。两种运行档案共享全部基础设施Benchbenchmarking/aws/scenarios/postgres/orders-cdc.yaml短时、最大负载的 CPU 扫描用于寻找吞吐上限Soakorders-soak.yaml、orders-soak-pr.yamlsoak: true长时、中等负载约为上限的 10-15%的耐力测试用于捕获内存泄漏、静默停顿与凭证轮换 bug。调度与 PR 触发.github/workflows/soak_nightly.yml——每晚 08:10 UTCcron 在默认分支上激活变更门控自上次 soak 提交以来无相关合并则跳过手动 dispatch 总是运行.github/workflows/soak_pr.yml——在 PR 上评论/soak需写权限在相同基础设施上做 base-vs-PR 对比并以置顶评论形式回帖。两者都通过 GitHub OIDC 认证不存密钥企业 license 从 Secrets Manager 获取。从笔记本运行# one-time (per account): persistent stack (dashboards, alarms, reaper, # OIDC, archive bucket) license secret — see SOAK.md cd benchmarking/aws task aws:persistent # builds cleanup-lambda/bootstrap.zip itself # validate a scenario (no AWS spend) task aws:validate scenariopostgres/orders-cdc # run a bench (~25 min infra sweep; ~$2-3) aws-vault exec profile -- env REDPANDA_LICENSE_FILEPATHpath \ task aws:bench scenariopostgres/orders-cdc # tear down after a failed/kept run task aws:down scenariopostgres/orders-cdcbenchmarking/aws/Taskfile.yml中定义的aws:validate、aws:bench、aws:down、aws:persistent、aws:cost-check、aws:summary等任务共同构成了这套命令行接口其中 runner 位于独立的 Go 模块benchmarking/aws/runner/因此构建后再在仓库根运行。运营铁律每条都源于真实事故细节见 SOAK.md同一时刻只跑一个 bench——所有会话共享同一份 Terraform state 与 stackrunner 的 pre-flight 在 bench EC2 存在时拒绝启动凭证必须比运行更长寿——aws-vault exec静态凭证约 1 小时失效优先使用 workflow 或 SSO 会话 profileCtrl-C 只能按一次——重复中断会在 destroy 中途杀掉 deferred teardown日志行不等于 teardown 证据——用 EC2/RDS 查询验证workflow 会自动完成若可能在 teardown 前切换分支请从 git worktree 运行。孤儿清理benchmarking/aws/cleanup-lambda/由 persistent stack 部署每 15 分钟运行销毁任何超过 4 小时的Projectredpanda-connect-bench资源。它刻意位于会话 stack之外——安全网不能与它所守护的对象共享生命周期。合法运行超过 4 小时需先禁用规则aws events disable-rule --name redpanda-connect-bench-orphan-cleanup结束后重新启用。Soak 测试的运行手册Soak 运行让一个连接器配置在持续中等负载下运行 90 分钟每晚一次让只有在运行期才会显现的 bug 类别——缓慢泄漏、静默停顿、轮换窗口、增长中的 lag——在客户发现之前暴露出来。各组成部分的分工如下表PieceWhereJobSoak scenariobenchmarking/aws/scenarios/engine/*-soak.yamlsoak: true持续负载档案验证到 1 cpu_point仅 connectRunner soak modebenchmarking/aws/runner/main.go、matrix.go、cloudwatch.go缩放节奏、10 分钟 S3 检查点、按分钟 CloudWatch 发射、backlog 序列Dashboards alarmsbenchmarking/aws/terraform/persistent/main.tf的soak_scenarios变量、alarms.tf每个场景一个 dashboard 三个告警stall / rss-slope / backlog→ SNSredpanda-connect-bench-soak-alertsArchive baselineredpanda-connect-bench-soak-archive存储桶每次运行的 result.json 原始产物soak-index/供滚动基线比较器使用不足 3 次运行仅建议此后吞吐 85% / RSS 130% 基线即判定失败Nightly workflow.github/workflows/soak_nightly.yml08:10 UTC cron 遍历轮换矩阵postgres、mysql串行、仅从默认分支取 arms 手动 dispatchOIDC 凭证4hlicense 来自 Secrets Managerteardown 对照 AWS 验证PR comparison.github/workflows/soak_pr.yml/soak评论写权限门控→ base-vs-PR 二进制、相同基础设施、置顶对比评论将新连接器加入轮换的步骤先跑或找到标准 bench 扫描确定其上限soak 速率应约为实测上限的 10-15%——soak 测试的是「长期正确性」而非吞吐量复制benchmarking/aws/scenarios/postgres/orders-soak.yaml并调整连接器/stack/管道/速率保持实例小巧postgres soak 用 db.r6g.xlarge c8g.xlarge。注意引擎特定的下限例如 RDS gp3 在 400GB 以下禁止配置 provisioned IOPS/吞吐。task aws:validate scenarioengine/name必须通过在benchmarking/aws/terraform/persistent/variables.tf的soak_scenarios中注册 dashboard 告警然后task aws:persistent——必须在轮换条目合并之前应用因为 cron 在 workflow 落到默认分支的瞬间就会武装自己将场景路径追加到soak_nightly.yml的 schedule 列表矩阵串行max-parallel: 1且fail-fast: false即使其他条目红也会继续 soak首次运行手动 dispatch nightly workflow 并输入场景名。基线比较器在存在三个 soak-index 条目之前保持建议状态可选添加 PR 变体*-soak-pr.yaml——相同场景、30 分钟时长、arms: [{id: base, binary: base}, {id: pr, binary: pr}]场景名必须与 nightly 的不同使其指标落在告警维度之外。告警渠道soak 期间的告警是急性渠道红色 nightly workflow 是构建间渠道/soak评论是合并前渠道。benchmarking/aws/grafana/soak-dashboard.json是一个可导入的 Grafana 面板覆盖相同的 CloudWatch 指标带连接器/场景的下拉、告警阈值与 CloudWatch 告警注解。已知限制详见 SOAK.md组织级ci-cloud-nuke每晚约 02:25 UTC 清扫该账户已多次删除 tfstate 锁表故后端改用 S3 原生use_lockfile锁、每晚解除孤儿回收器的调度规则并删除 stall backlog 告警——豁免手段是cloud-nuke-excluded true标签postgres_cdc 的 IAM 认证无法用于 vanilla RDS复制协议连接拒绝 IAM 令牌因此 postgres soak 无法覆盖凭证轮换窗口该职责由 mysql soak 承担GitHub 会在公共仓库 60 天无活动后禁用 cron workflow。成本控制一次 postgres bench 运行约 $2-3一次 nightly soak 约 $5变更门控跳过的日子为 $0。最坏情况的 stranded-stack 由回收器的 4 小时 TTL 兜底。task aws:cost-check可通过 AWS Cost Explorer 直接查看当日/7 天/本月支出。结语从internal/impl/component/bench/的自包含本地套件到benchmarking/aws/的生产级 AWS 基准与 soak 浸泡框架Redpanda Connect 的基准测试体系覆盖了「开发期验证」到「上线前持续回归」的完整链路。其核心方法论可概括为真实依赖生产镜像而非 lite 变体、真实数据多 schema、贴近实际行大小、可复现环境CPU 钉扎 内存限制 Go 运行时调优、隔离测量drop: {}benchmarkprocessor、以及透明的汇报机制PR 描述 docs/benchmark-results/结果文件 滚动基线。遵循这套流程任何连接器性能变更都可以在合并前被客观量化与回归把关。【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考