前阵子接手一套CRM中间件入站队列半夜到早上持续堆积的故障订单和客户主数据卡在SMQ2里出不来界面一刷新就多几百条。这类问题靠看日志、翻事务码通常只能看到表面现象真正要定位到“是应用逻辑慢、数据库等锁、还是队列调度设置不合理”必须有一套能在隔离环境复现和压测的方法。我后来把整套动作梳理下来发现完全可复制成标准流程用SATSAP Application Test在恢复环境录制、回放CRM中间件入站处理链路制造可控的qRFC压力再同步采集队列深度与系统指标逐层读数据。本文就把这条qRFC性能定位方法完整拆开适合SAP顾问、Basis运维和CRM中间件管理员直接参考。1. 先搞清战场CRM中间件的入站队列到底怎么堵的1.1 qRFC与入站队列一条流水线上的“顺序工位”SAP CRM中间件Middleware是CRM与ERP、其他外围系统之间数据交换的枢纽订单、客户主数据、产品信息都是以BDocBusiness Document为载体通过qRFC队列机制跨系统传递。qRFC就是queued RFC它在普通RFC基础上增加了队列概念保证同一队列里的消息严格按顺序投递、并且“只处理一次”不会因为网络重试或业务崩溃导致重复处理。入站这一侧CRM系统在SMQ2里维护所有Inbound Queue。它的工作方式很像我常给同事打比方的一条流水线传送带把包裹送过来但工位上只有一个工人一次只能拆一个包裹拆完一个才允许拆下一个。任何一个包裹处理时间变长后面所有包裹全部原地等待表现在SMQ2上就是队列深度越堆越高。qRFC为了保证业务一致性要求同一个队列内的消息在一个逻辑工作单元LUW内串行提交这个“串行闸门”既是正确性保障也是性能瓶颈最容易出现的位置。实际生产里入站队列的堆积往往是渐进式的白天业务量小处理速度勉强跟得上傍晚大批订单导入系统又正好跑着月结或同步作业队尾越排越长。等业务人员第二天上班一查界面已经积压上万条BDoc。需要明确的是堆积本身不是一个“错误状态”这是qRFC的正常排队表现真正的病灶在于单条消息的处理耗时上升、或者整体处理能力无法满足峰值流量。所以我们做性能体检目标不是看队列里有多少条而是搞清楚队列“消化一条消息到底需要多久、在哪一步被拖住”。1.2 为什么队列常年堆积性能问题却说不清楚很多项目遇到入站队列堆积常规动作是打开SMQ2手动执行一次队列处理看还报不报错没报错就觉得是“临时堵车”继续等。但生产环境不能随便压测数据也不能乱动于是问题往往反复出现今天清了队列明天又堆起来业务部门和IT像在玩打地鼠。更深层的原因是性能问题需要“可控的重现定量分析”才能定位而生产环境恰恰不满足这两个条件。你不可能在生产库上重启队列或开SQL跟踪看每条消息的执行计划也没法控制消息类型、量级和频率来做对照实验。退一步说即使能看ST05的跟踪结果手工发起几条BDoc事务也压不出真实高峰期的效果数据样本太少结论自然站不住脚。所以我的做法是把性能验证从生产搬到恢复环境。用SAT录制一条真实的CRM中间件入站处理操作路径然后把这条路径扩成多用户并发脚本用脚本去“注入”可控的qRFC负载同时把队列深度、CPU、数据库时间等指标按时间轴对齐采样。压测结束后生产的问题通常能在测试环境稳定重现该查锁查锁、该拆队列拆队列每一条优化动作都能用同一套压测脚本做前后对比。这就是标题里说的“可复制”三个字的分量。2. 选型与测试设计SAT凭什么能做这件事2.1 三类压测工具对比SAT、LoadRunner、自写批处理做SAP性能压测市面上常见三条路商用工具比如LoadRunner、SAP自带的测试平台SAT、还有项目组自己写ABAP批处理或者塞RFC请求。我三者都试过这里给出我的真实对比结论。LoadRunner这类协议级压测工具擅长的是海量并发、跨服务器的整体压测但脚本录制通常走SAP GUI协议或web服务和RFC代理配置成本高而且它生成的负载在CRM中间件这种强业务上下文的场景里经常需要大量二次适配比如会话状态保持、批量数据生成、队列状态的校验否则压出来的只是“表面流量”根本没碰到真正的业务逻辑。自写批处理看起来简单用一个程序循环调RFC函数或者用ABAP在后台不停调用入站处理函数通用性却很差。R3AC1里配置了哪些BDoc类型、BDoc的依赖关系、出站联动如何屏蔽都得针对每个项目单独改代码写一个能真实模拟业务消息的批处理Days起步。它适合做功能测试不适合做灵活的性能压测。SAT是SAP自身生态的工具事务代码SAT核心是eCATT脚本。它是录制GUI操作再回放的方式天然带着SAP的会话上下文。录制时你做了什么、等了多久、点了哪个事务码回放时就原样执行中间还能插入同步点、参数循环和结果校验。配置多用户并行运行也简单不需要额外买license、搭压力机。对于“CRM中间件入站队列性能体检”这个任务我的结论很明确优先SAT。它录的是用户实际操作路径恰好SIMULATION了SMQ2界面操作里那些“点击‘进程’按钮、等待状态变化、退出”的真实动作回放时能触发完整的中间件逻辑。LoadRunner留到将来做端到端全链路压测时再考虑。2.2 一套可复制测试方案必须具备的四个要素用SAT录制回放只是“能跑”要形成可复制的方法还需要在测试设计上做好四件事。第一隔离下游依赖。CRM中间件处理入站BDoc时经常要触发分配给其他系统的出站队列比如把消息同步回ERP。如果不屏蔽出站压测产生的负载可能会顺着出站队列传到下一个系统既污染下游环境也让我们的入站测试结果混入“出站并发”的干扰因素。所以录制脚本前要确认测试环境的出站队列已经按目标系统停用或用测试目标系统替代真实RFC配置。第二参数化业务数据。性能压测不能永远只回放录屏时那几条消息。SAT支持用数据集文件给脚本变量喂值比如队列名、BDoc类型、关键单据号。我们要从生产备份或者测试环境里挑一批有代表性的BDoc作为输入样本让负载分布接近真实高峰期的消息组合而不是所有的虚拟用户都在重复处理同一条记录。第三保证观测数据的可对齐性。压测之后最怕的就是各干各的SAT报告显示事务平均响应时间200毫秒ST05里看到某条SQL跑了2秒SMQ2截图显示队列深度曾到8000但这三份数据对不上时间点等于白测。建议所有指标采集都以压测开始时间为零点同步记录每30秒或1分钟的采样点。第四固化脚本、参数和配置基线。一套可复制的方法必须能做到“今天跑完三个月后还能原样再跑一次”。脚本文件、数据集、SAT运行配置、SMQ2的初始状态全部命名归档二开时只改参数不重录脚本。我见过太多团队压测完连脚本都没从环境里导出来下次想复测只好从头来前功尽弃。3. SAT压测实操从录制脚本到指标采集3.1 第一步录制一条完整的入站处理链路打开SAT新建eCATT脚本开始录制。录制前把恢复环境恢复到“干净状态”SMQ2里没有历史堆积已处理队列清空这样压测开始后新增的任务就是我们自己制造的负载。录制路径是这样的登录CRM客户端事务代码SAT或SECATT进入eCATT编辑器创建测试脚本并启动录制器接着启动一个新的SAP GUI会话在会话里走一遍入站处理的完整操作。先打开SMQ2输入目标入站队列名称回车查看队列表然后选择队列点击执行/处理按钮触发一次处理操作处理过程中在界面上等待队列状态变从处理中回到Ready或Finished再刷新队列总览确认条数变化最后退出事务。每一步操作都会被录制器捕获包括界面元素的名称、输入值和菜单路径。这里有个关键点录制的动作不要太多够覆盖一段完整业务链路即可。我见过有人把登录后的各种信息查询、导航操作全录进去回放时长被人为拉长导致结果里掺杂了大量无关系统开销。你是不是也想让记录库里保留“真实操作路径”我的建议是中间件入站场景的脚本范围就是“进队列→处理→等待反馈→刷新→退出”。登录动作单独作为一个前置脚本处理不合并进主体压测脚本便于复用。录制结束后SAT会生成一份eCATT脚本脚本内部保存了会话的每个交互步骤。接下来把脚本打开删掉不必要的屏幕确认弹窗处理把硬编码的队列名和关键参数改成变量。eCATT脚本语言类似ABAP结构上能非常直观地看到“参数定义区和命令执行区”不用会写完整ABAP会配变量就能改。3.2 第二步参数化与并发模型让压力不像DEMO改参数化时我在脚本顶部维护一个参数列表常用的是这几项queue_name入站队列名、bDocTypeBDoc类型、iterations单用户循环次数。然后在脚本执行区用循环语句包住“选择队列→处理”的关键步骤循环次数取自iterations。数据集文件则放在SAT运行配置里用Excel或CSV一行一条消息参数组合SAT会按行分配给各虚拟用户。接着配置并发模型。第一次压测不要恋战按“基线→单用户→多用户”的台阶来。用估算公式算目标TPS取业务高峰期的小时处理量除以3600得到每秒需要处理的消息条数再乘上至少2倍的安全余量作为压侧目标吞吐。比如高峰期每小时处理3600条BDoc就是每秒1条压测目标定在每秒2至3条。如果15个并发用户已经能稳定达到这个TPS说明系统峰值能力有余量如果加压到5个用户TPS就上不去了那多半是某个环节的串行瓶颈出现了。多用户并发在SAT里通过Test Run/Test Configuration实现SAT支持配置虚拟用户数、并发启动时间、执行次数还能控制每个虚拟用户各用一套参数文件。启动时挨个命中在同一个测试场景里组好然后一次性提交运行。设置并发时注意一点每次迭代之间至少要保留队列状态刷新和短暂回退时间否则虚拟用户在界面上的操作会互相抢占同一个GUI元素句柄报各种莫名错误最后看报告“失败率90%”都不能体现真实压测结果。3.3 第三步同步采集系统与队列指标压测开始前我先花10分钟把“数据采集表”准备好压测时按表格逐项记录。这里整理一份我常用的采集清单采集项事务码/工具采集方式入站队列深度趋势SMQ2每30秒刷新一次队列总览记录条数工作进程状态SM50压测期间按需抓取记录进程数和运行模式系统负载/事务响应ST03N压测结束后按时间段导出工作负载分析数据库请求时间ST05或DBACOCKPIT对重点事务开SQL跟踪记录DB Time与锁等待CRM中间件消息处理跟踪R3AC1/R3AM1及相关监控开启BDoc处理级别跟踪观察处理耗时分布SAT脚本运行报告SAT执行结果每线程总耗时、平均响应时间、失败事务数采集的注意点在于“对齐时间”——所有工具都记录压测开始后的分钟数。比如我启动SAT压测后在同步记录表第一行写下“第0分钟SMQ2深度320ST03N随后参照”每30秒在SMQ2和系统监控两个窗口之间切换记录一次。清一清画面不要怕麻烦后续定位就是用这些时间点把各项指标串成一条线。有条件的话开ST05只跟踪压测涉及的核心事务码对应的表操作不要全系统跟踪否则庞大的日志量会把恢复环境拖垮。压测结束第一件事是先停ST05再保存SAT报告最后才去整理SMQ2的最终状态。4. 数据解读与瓶颈定位体检报告看哪里4.1 队列深度曲线的三种形态分别代表什么压测过程中我习惯把SMQ2队列深度随时间的变化画成一个简单折线图手工在纸上或者用Excel即时录入。队列深度曲线基本就三种形态分别指向三类问题。第一种是“先堆后平”压测刚启动的1至2分钟内队列深度快速上升因为虚拟用户同时把大量消息投进队列处理还没起来随后曲线走平说明入站处理速度已经追上了投递速度系统是正常“稳态”表现。这种情况下只要TPS达标就没有性能问题。注意曲线的“堆高高度”不代表故障只能说明队列允许积压、符合qRFC设计。第二种是“一直堆”队列深度从压测开始到结束持续上升没有走平迹象。这代表投递速度稳定大于处理速度系统处理能力是明确不足的。接下来就要关注CPU、DB Time和事务响应时间判断是持续处理不过来了还是出现了错误重试循环。第三种是“平后又堆”前面处理正常运行到某一刻开始掉头向上。这种情况最常见的原因是数据库缓存逐步用完或锁范围扩大或者是SAT并发用户进入特定的数据子集导致某个队列始终拿不到锁。它对应的是“间歇性瓶颈”往往需要翻ST05跟踪记录看突变时间点发生了什么。4.2 一个真实复盘的体检案例CPU不高DB在等锁讲一个我最近拿SAT实际复盘的案例为了叙述方便模糊掉具体公司和数据。场景是某制造企业的CRM订单主数据导入入站队列在每天17点批量导入时段堆积。我们在恢复环境灌入同样的BDoc数据用SAT脚本按15个虚拟用户并发压测同步采集了5分钟指标。第一轮压测数据是这样的队列深度在前90秒冲到约1.2万条之后以每分钟几百条的幅度继续缓涨同期ST03N显示应用服务器CPU使用率只有28%空闲得很但DB时间里等待锁的占比接近70%。看到这个组合基本就能把瓶颈从“应用逻辑太慢”排除到“数据库层存在锁竞争”。随后用ST05对入站处理期间的表操作做分析发现消息头表、状态表上一次性插入的行数很大两条不同消息在更新同一批号码段后出现锁等待单条消息的数据库时间从正常的50毫秒被拉到400多毫秒。锁竞争的直接效应是队列单个LUW的处理时间被放大队列串行机制又把这个时间损失原样传导给后续所有消息。定位思路是15用户并发模拟时所有虚拟用户选用的是同一组号码段区的数据样本这在生产批量场景确实会发生真实瓶颈不在并发用户多而在消息内部有段更新持锁时间过长。解决办法是把一条消息内的三次表更新合并为一次、并调整号码段分配策略削减持锁窗口。调整后跑第二轮压测同样的SAT脚本、同样15用户队列深度在约1分钟就走平TPS从1.8提升到5.3锁等待比例降回8%。这个前后对比直接证明了优化动作有效。整个过程用同一套脚本、同一套数据、同一个观测方法这就是“可复制”在实践中的价值。4.3 定位瓶颈的顺序应用、数据库、队列调度拿到SAT压测和系统采样的数据后我习惯按“从快到慢”的顺序逐层排查而不是一上来就猜数据库。第一层看应用服务器处理逻辑。ST03N里事务平均响应时间高不高CPU忙不忙。CPU接近饱和说明问题大概率在应用代码的循环、或消息处理的业务逻辑太重这时候去SE30做单事务的运行时分析找出消耗最集中的ABAP代码。第二层看数据库执行时间。CPU没跑满但ST05显示数据库时间占事务总时间的比例很高就要看SQL是否走了全表扫描、有多少锁等待。这里要把DB Time按表聚合找出被频繁更新的表和锁。CPU与DB Time都很低、但TPS就是上不去才是队列调度层面的串行限制。第三层看队列调度设置。排除上面两者后瓶颈往往在qRFC的串行设计或调度配置上消息粒度是否过大一条消息塞了几十个BDoc导致单LUW过长、是否把所有入站消息放在同一个队列里互相阻塞。优化方向是把消息按业务类型拆到多个队列并行处理或者修改发送端的组包逻辑让队列里的消息颗粒更小。每调整一项都回到同一个SAT压测脚本去复测看TPS和队列深度曲线的变化。5. 常见问题与避坑实录5.1 高频问题速查表把我这几年跑CRM中间件压测时遇到的典型问题整理成一张速查表遇到类似现场可以直接翻。现象可能原因处置方法SAT回放时报GUI元素找不到录制界面与回放版本不一致或弹窗被拦截统一GUI版本录制后手动检查脚本中屏幕元素回放前关闭所有弹窗增强功能压测时SMQ2操作频繁报锁冲突多个虚拟用户同时选中同一队列并处理队列名参数化保证每个用户操作不同队列或适当调整并发阶梯队列深度暴涨但CPU/DB很低入站消息绝大多数在排队没真正进入处理检查队列状态是否处于停用确认队列调度器已被触发查看是否有错误队列在反复重试压测结果不稳定两次TPS差很多数据集文件行数不足虚拟用户重复拿同一样本扩展参数数据集按用户维度分配数据子集压测前重置队列状态压测后发现测试环境队列被污染测试消息混入正常队列后续功能测试无法进行压测前备份SMQ2队列内容压测后对目标队列执行清空/回滚动作SAT报告显示大量超时失败GUI回放响应等待时间太短或并发过高触发会话互斥在脚本中增加同步点和等待时间并发用户数减半重新试跑5.2 实操后才明白的三个细节有些经验写不进工具文档但踩过坑之后就很难忘。第一压测前务必备份队列内容。恢复环境再“干净”也可能残留别的项目组丢进来的测试消息。我在一次压测前没看队列结果SMQ2里还躺着几条旧报错消息压测刚开始它们就在队列最前面被反复重试导致头十分钟的处理吞吐被拖成零。现在我的标准动作是压测前打开SMQ2把队列里所有条目按队列和消息号导出保存做完压测再对照差异。第二别在压测期间让其他后台作业“抢戏”。测试环境服务器上经常挂着各种定时任务、ABAP程序、甚至别人的压测脚本。一次性能体检如果打了一半突然有批处理把数据库资源吃掉数据曲线就会出现莫名其妙的台阶。我的建议是开压测前检查SM37把无关的后台作业挂起或改调度时间压测结束后再恢复。第三队列深度的记录频率要匹配业务节奏。半分钟一次适合慢速堆积但一条消息处理只要几十毫秒时队列深度可能在你点击刷新的间隙就大幅波动。更可靠的做法是连续开两个session一个固定停在SMQ2上连按F8刷新另一个记录系统指标把刷新次数和深度变化用秒表打点。别嫌土很多时候手工打点比事后从数据库调日志更直观。写在最后的个人经验这套方法从第一次在项目里完整跑通到现在已经成了我处理CRM中间件入站性能问题的标准动作。每次复盘时我都提醒自己压测的目的不是把系统压垮而是用一个主动、可控的方式让系统告诉我们它在哪一段最吃力。SAT脚本只是手段真正的功夫在“测试设计”和“数据解读”两句。如果你刚接触这类问题建议先从一台恢复环境、一个队列、一份数据集和一份采样表格开始按本文的步骤完整走一遍。第一次不一定跑得漂亮但跑完后你会对qRFC的串行特性和系统响应机制建立非常直观的感觉下次再遇到生产队列堆积你会多一分“手里有图、心里有数”的底气。