常见的认知：规则越多，判定越准，性能靠硬件扛
很多维护AB页跳转系统的团队，项目刚开始那会儿都有个默认想法——判定准不准，主要看规则覆盖得全不全。规则越细越多，流量切分自然就越精准。至于性能嘛，服务器不够就升级，几毫秒的决策延迟对跳转来说能有多大影响？于是规则库从几十条涨到几百条，再涨到几千条，中间几乎没人停下来问一句：这么多规则叠在一起，单次判定到底要花多久？
这个想法在规则量小的时候确实没毛病。一两百条以内、主要是精确匹配的话，现在随便一台服务器都能把决策耗时压在亚毫秒级别，升级硬件确实能把大部分性能损耗遮过去。但规则规模往上走的时候，事情就变了。它不光是查询次数变多，规则之间的依赖关系、触发顺序、回退路径全都在跟着变。一旦跨过某个临界区间，决策耗时开始疯涨，涨得比规则数量快得多。到那会儿再加CPU核心也压不住延迟曲线了。
AB页跳转性能基线要弄明白的就是这件事：在给定的规则结构和运行环境下面，规则规模涨上去之后，决策耗时跟着怎么变，拐点在哪儿，维护的人应该在什么时候停下来做规则治理，而不是继续往里堆。
性能基线的四个构成维度
AB页跳转性能基线不是一个单纯的延迟数字，它是一组可以观测、可以复现的度量条件。具体由四个维度组成：规则规模、规则结构、流量特征，还有决策耗时分布。
规则规模与结构
规则规模看两个指标。一个是规则条数，就是当前在生效的判定规则总共有多少。另一个是规则复杂度，包括匹配条件用了几个维度、有没有正则、是不是嵌套逻辑、要不要依赖外部数据源比如IP库或者设备指纹服务。复杂度这东西直接决定单条规则最坏情况下要花多少时间。同样是一百条规则，全是精确URL匹配的，跟一百条带正则全文扫描的，决策耗时能差出二十倍以上，一点不夸张。
流量特征
流量特征决定规则集的命中分布长什么样。如果九成请求都命中了前百分之十的规则，性能退化就被盖住了，根本看不出来。反过来，如果流量很散，命中位置普遍靠后，那每次判定都得遍历一大半规则才能找到目标或者确认没有匹配，决策耗时自然就上去了。流量特征还包含请求的并发模式和突发比例，这些影响队列等待时间，最终反映到端到端延迟上。
决策耗时分布
单次判定耗时得用分位数来说话，光看平均值没意义。P50告诉你典型请求大概要多久，P99告诉你尾部延迟有多糟。AB页跳转这个场景里，P99比P50更能暴露规则膨胀的问题。一条平时不太命中的复杂规则，碰上某种流量取向突然集中出现的时候，能把尾部延迟拉出一个很长的尾巴。所以性能基线的退化曲线一般P50和P99两条线并排画，只看均值会把风险藏起来。
运行边界包括服务器什么配置、用的什么语言、规则引擎是哪种、缓存命中率多少、外部依赖响应快不快。同一套规则集放在边缘节点和放在中心服务器上，退化曲线完全不同。放在带预编译的规则引擎里和放在自己写的解释执行逻辑里，也不一样。性能基线必须把运行边界标清楚，离开运行环境谈退化曲线，等于没有参照系。
规则规模增长如何推高决策耗时
规则数量涨上去带来的耗时上升，画出来不是一条直线，而是一条先平后陡的曲线。要看懂这条曲线为什么长这样，得把决策链路拆成输入、处理、输出三个阶段，挨个看它们各自发生了什么。
输入阶段：请求特征提取开销
每次跳转判定开始之前，系统得先从请求里把需要用的特征提出来：URL参数、User-Agent、IP归属、设备指纹、Cookie状态、来源Referer这些。规则越多，要提的特征面就越宽。最开始的规则只查URL和UA，提取成本基本可以忽略。后来为了把流量分得更细，规则开始依赖设备指纹、ASN归属、浏览器环境一致性这些玩意儿。每多一类特征，输入阶段的提取耗时和失败重试概率就往上加一层。而且特征提取经常要调外部服务，这种网络往返的时间比本地计算高两三个数量级。所以规则规模增长在输入阶段的表现，其实是特征依赖爆炸，不是简单地说规则查询变慢了。
处理阶段：匹配遍历与规则间依赖
处理阶段是退化曲线的大头。规则匹配在逻辑上有三种组织方式：顺序遍历、索引命中、规则树。顺序遍历的时间复杂度和规则数成正比，规则树在主条件上能做到对数级，但附加条件一多就退回线性扫描了。大部分AB页跳转系统的规则都是顺序优先的，按优先级从上往下一个一个判，命中就停。这种模式下，规则规模涨多少，平均遍历深度就跟着涨多少。
比这个更隐蔽的退化来自规则之间的依赖。规则A的判定结果可能决定规则B要不要参与判定，规则B命中了又可能改掉规则C的匹配条件。这种依赖让决策路径从一条直线变成一张有分支的图，最坏路径长度可能呈组合级往上翻。维护的人加规则的时候一般只评估这条规则本身贵不贵，很少有人去算它加进来之后对整条决策路径长度贡献了多少。
输出阶段：动作执行与回退处理
规则判定完了之后，输出阶段负责把跳转动作执行掉：返回302、渲染JS跳转、输出中间页，或者走回退逻辑。规则越多，动作类型就越杂，回退链也跟着越绕。一条规则命中之后可能触发好几个后续动作，每个动作又有自己的超时和重试策略。规则集膨胀到需要多层回退保护的时候，输出阶段在整条决策链路里的耗时占比能从不到百分之十涨到接近三分之一。退化曲线最陡的那一段，很多时候不是匹配本身变慢了，是回退路径一层一层叠出来的。
退化曲线的形态与拐点判定
规则规模增长和决策耗时之间的关系，大致可以用一条幂律型曲线来近似。规则规模小的区间，耗时增长接近线性，斜率比较缓。等规则间依赖多了、特征提取成本上来了，耗时增速就超过线性了，曲线开始往上翘。拐点具体在哪个位置，取决于规则结构和运行边界，不存在一个放哪儿都准的固定数字。
判断拐点比较靠谱的办法是做分段压测。把规则集按规模切成几个档，比如一百条、三百条、八百条、两千条，在同样的流量特征下分别测P50和P99。要是相邻档位之间P99的增幅明显大过规则数量的增幅比例，那基本就进入了退化加速区。还有一个信号是看耗时对流量特征的敏感程度。同样规模的规则集，集中命中分布和均匀分布下P99的差距拉得越大，说明规则集对最坏路径的依赖越重，再往里加规则的风险就越高。
缓存能改变曲线形状，但消不掉退化本身。规则判定结果缓存、特征提取结果缓存都能把重复请求的耗时降下来，问题是AB页跳转的判定结果特别依赖请求特征的组合，流量特征一分散，缓存命中率就掉得很快。缓存对P50的改善通常比对P99明显，尾部延迟的退化该怎么在还在。
一个规则膨胀的实际案例
有个做社交电商的投放团队，日均点击量一千二三，服务器是一台四核八G的单节点，规则引擎用的是自研的PHP顺序匹配。刚开始只有九十多条规则，主要按来源渠道和落地页分组做跳转，P99决策耗时在十毫秒以内。过了半年，规则涨到七百多条，原因也挺正常：新增了好几个投放平台、按地域细分了落地页、又加了设备环境判定逻辑。这时候P99已经到四十几毫秒了，P50还在十五毫秒左右，团队没太当回事。真正出问题是在投放旺季流量翻倍之后，服务器CPU使用率长时间贴着上限跑，P99飙到一百八十毫秒以上，部分请求在规则匹配阶段就超时走了回退页，转化数据出现了明显的断点。
事后排查发现两个问题。头一个是规则从九十多条涨到七百多条的整个过程中，从来没做过废弃规则清理。里面有将近两百条规则因为活动结束或者平台调整，已经永远不会命中了，但每次判定还是得把它们遍历一遍。第二个问题是设备环境判定这条特征依赖一个外部指纹服务，峰值流量下这个服务的响应从三十毫秒退化到两百毫秒以上，所有依赖这条特征的规则全被拖慢。处理分两步走：先清无效规则，把规则集压回三百条出头；再给外部特征服务加了三秒超时和本地缓存。调完之后P99回到五十毫秒以内，CPU使用率降了四成。这个案例说明一件事，规则治理不是可有可无的维护项，它直接决定跳转链路还能不能扛得住。
性能基线的适用条件与维护边界
AB页跳转性能基线的设定和维护有几个明确前提。第一，运行环境得固定下来做对比测量。换个服务器或者换个规则引擎，原来的基线数据就没法用了，得重新标。第二，基线数据要跟流量特征绑在一起。同一套规则集在不同流量分布下表现不一样，拿旺季峰值的基线去指导淡季的容量规划，结果肯定失真。第三，基线得定期更新。规则集每次有结构性变化，比如新增了依赖外部服务的规则、引入了新的特征维度，都应该重新跑一次基线测量。
性能基线也有它管不着的地方。它只能描述规则规模和决策耗时之间的关系，回答不了规则本身对不对、会不会误伤真实用户。它也不涵盖跳转动作执行之后的页面加载时间和转化链路质量。要是把性能基线当成AB页跳转系统健康度的唯一指标，规则逻辑层面的风险就全漏掉了。
与相邻概念的关系
性能基线跟容量规划是两码事。容量规划回答的是给定资源下能扛多大流量，性能基线回答的是给定规则规模下决策要花多长时间。容量规划盯着吞吐，性能基线盯着单次判定延迟。两者有关系，但度量目标和优化手段都不一样。规则引擎压测和性能基线也有区别。压测更偏重找系统在极端条件下的崩溃边界，性能基线更偏重描述规则规模变化带来的持续退化趋势。一个是突击测试，一个是长期跟踪。
AB页跳转性能基线跟普通页面跳转的性能优化也不完全是一回事。普通跳转的延迟优化主要看DNS解析、TCP连接、TLS握手和服务器响应时间。AB页跳转在这些基础延迟之上，额外多了一层规则决策耗时。这层耗时是AB页跳转特有的、可以修剪掉的成本项。把规则规模和决策耗时的退化曲线搞明白，其实就是搞清楚这层成本什么时候从可忽略变成了不可忽略。
