多会话多调用场景下A/B测试执行延迟评估指标选型咨询

这是个很实际的A/B测试指标选择问题，结合你的场景（每个用户会话调用foo()次数可变，延迟范围1-400ms），我来拆解一下现有选项和其他可行指标：

现有选项的优劣势 #

1. 计算每个会话的平均值后评估CDF #

• 优点：平均值乘以会话内调用次数就是该会话中foo()的总耗时，能直接反映用户在整个会话里为这个函数付出的总等待时间。对于调用次数多的会话，总耗时是用户体验的关键——毕竟多次调用累积的等待感会更明显。
• 缺点：平均值容易被极端大值（比如你例子里的280ms）拉高，可能会高估某些用户的整体延迟体验。比如一个会话里只有1次慢调用，其他都很快，平均值会被这个异常值带偏，不能准确反映大多数调用的实际速度。

2. 计算每个会话的中位数后评估CDF #

• 优点：中位数不受极端值影响，能精准反映会话中一半调用的延迟水平，更贴近用户“大多数时候的感受”。比如刚才的异常值场景，中位数依然能体现大部分调用的快速，不会被少数慢调用干扰。
• 缺点：中位数忽略了总耗时和调用次数的影响。比如一个会话调用1000次、中位数10ms，总耗时可能远高于另一个调用10次、中位数15ms的会话，但中位数指标会认为前者更好，这和用户实际的等待体验可能不符。

其他可选指标 #

除了上述两个，还有几个更贴合用户体验的指标值得考虑：

• 会话总耗时：直接计算每个会话中所有foo()调用的延迟总和，再做CDF分析。这个指标最直接反映用户在整个会话中为该函数付出的总等待时间，尤其适合调用次数差异大的场景——调用次数多的会话，总耗时的累积效应会直接影响用户体验。
• 会话内的p95/p99延迟：计算每个会话中所有调用的95th或99th百分位数，再做CDF。用户往往对偶尔的卡顿更敏感，p95/p99能捕捉到会话中极少数的慢调用，帮你判断哪个算法更不容易出现“突发卡顿”。比如如果Algo1的p99延迟远高于Algo2，说明Algo1偶尔会出现让用户明显感知到的慢调用。
• 会话内超阈值调用占比：先设定一个用户能感知的延迟阈值（比如100ms，可根据业务场景调整），计算每个会话中延迟超过该阈值的调用次数占总调用次数的比例，再做CDF。这个指标能直接衡量用户遇到“慢调用”的频率——如果一个算法的超阈值占比更高，用户会更频繁地感觉到卡顿。

指标选择建议 #

最终选哪个指标，取决于你的核心优化目标：

• 如果目标是减少用户整体等待时间：优先选「会话总耗时的CDF」或「会话平均值的CDF」（两者趋势高度相关，总耗时更直观）。
• 如果目标是优化大多数场景下的流畅度，或想排除极端值干扰：选「会话中位数的CDF」。
• 如果目标是降低用户遇到卡顿的概率：选「会话p95/p99延迟的CDF」或「超阈值调用占比的CDF」。

实际测试中，建议同时观察2-3个指标，因为单一指标可能无法全面覆盖用户体验——比如某个算法总耗时低，但p99高，说明它大部分时候快，但偶尔会卡，这时候就要结合业务场景判断（比如实时交互场景更在意卡顿，后台任务更在意总耗时）。

内容的提问来源于stack exchange，提问作者sbr