每天上百万通话，携程电话系统性能测试实践

一、背景

作为全球领先的在线旅游企业，携程注重服务质量，并拥有全球最大的旅游呼叫中心，分别部署在国内自建系统、国内和国外第三方云服务平台上。呼叫中心每天承接着上百万通的通话，电话服务系统是整个呼叫中心中非常重要的一套系统，服务着数万客服座席，系统的稳定性至关重要。

二、性能测试开展

2.1 原因

旅游受季节和时间的影响比较大，五一和十一等长假期间旅游量会暴增，随着业务的暴增，电话咨询和反馈也会随着增加。对于研发人员来说，掌握负责系统的性能指标来迎接随之而来的业务高峰非常重要。因此研发团队会不定期的做系统的性能压测，来评估和衡量业务高峰期间带来的系统压力。

2.2 工具

目前 SIP 协议性能测试一般采用基于流程的测试方法，流程指一个成功的 SIP 会话所包含的 SIP 实体双方交换消息的类型和顺序。且测试应当根据被测设备特点，通过实现对特定呼叫流程场景的模拟来实现，因此测试工具应当支持符合呼叫流程要求的信令与媒体流发送与接收。

测试的开展首先是选取测试工具。SIPp 是一个测试 SIP 协议性能的工具软件，它包含了一些基本的 SipStone 用户代理工作流程（UAC和UAS），并可以使用 INVITE 和 BYE 建立和释放多个呼叫，当然 SiPp 还有许多其他的功能，比如通过读 XML 场景文件，模拟 SIP 信令来重现故障等等。SIPp 与我们常用 Http 协议的性能测试的工具有着一定的不同，当然熟练使用 Loadrunner 等工具对 SIPp 的使用也有一定帮助。

2.3 系统架构分析

对于性能测试的指标的选取，需要结合被测系统的架构（如图 2-1），从而设计出相应的压测场景和具体实现脚本。

2-1 电话系统结构流程图

2.4 测试脚本设计

用 SIPp 做测试的必要文件：

uac.xml：根据需要编写的 uac 侧的 sip 信令流程。

uas.xml：根据需要编写的 uas 侧的 sip 信令流程。

uac.xml 和 uas.xml 用来模拟 SIP 消息流程，

data.csv：用于 uac.xml 和 uas.xml 中需要引入的数据，例如分机号，被叫号码等等。

uac.bat：调用 sipp 命令，并传入相应参数的批处理文件，模拟 UAC（主叫）。

uas.bat：调用 sipp 命令，并传入相应参数的批处理文件，模拟 UAS（被叫），

2.5 目标

a. 验证和确保呼叫中心系统支持最大并发通路，使得用户能接入座席进行咨询和沟通或进行 IVR 流程操作，以及超出阈值后，会进行熔断，不再增加系统压力，确保当前服务运行正常。

b. 高并发的异地分配准确性。

2.6 场景设计

根据系统的场景，我们对系统的 2 个方向进行压测。

a. IVR 和 PBX 分配的限流保护措施。

• PBX 排队溢到 IVR 的场景。

携程呼叫中心分三地，各地区根据业务量不同分为一套或多套 PBX 服务，每套 PBX 针对技能组和整套服务都做了限流，所以此场景我们目的是为了验证当 PBX 技能组达到限流时候系统会将电话溢出到 IVR 流程的场景，来确保当前服务的正常和可用。

• 正常 IVR 满后，分配到溢出 IVR 的场景

正常可服务 VR 服务同样是有系统限流措施的，所以这个场景，我们的目的是验证当达到正常的 IVR 限流数量之后，会溢出到溢出 IVR 流程，溢出 IVR 流程进行语音播报：“当前系统繁忙，请稍后再拨”。

• 正常 IVR 和溢出 IVR 全部满之后，电话无法呼入到 IVR 的场景

当 PBX，正常 IVR 和溢出 IVR 都达到限流时，其余拨打进来的电话无法再拨通。目的是为了保证此时当前系统的稳定性

b. PBX 的异地分配准确性

多个地区的呼叫中心，每个地区都有服务同一个业务线的坐席，所以会涉及到多个地区的电话异地分配，根据 EWT（Excepted Wait Time）进行异地分配，在高并发场景验证系统的分配准确性。

压测服务器配置如下：

2.7 执行压测

当压测方案和压测脚本都准备完成后，接打所使用的分机都需要先进行注册，如果需要使用的分机数量在比较大的情况下，建议另外先编写注册分机的脚本。压测运行结果如图 2-2。

2-2 运行结果

压测过程中需要注意的几个点：

（1）先开启被叫，再开启主叫；如果先开启主叫，被叫没开启会出现异常，影响压测数据的准确性。

（2）压测过程中观察对应的异常，来判定抛出的异常原因，排查对应的 error-log 来确认是否是所压测的系统问题或者是系统配置问题。

（3）需要抓取被压测服务器的内存和 CPU，在压测前通过服务器监控平台设置指标进行监控。

2.8 运行结果分析

针对上一小节的场景设计，运行结果如下：

• PBX 排队溢到 IVR 的场景

酒店 VDN 对应南通和上海两地有两个 VDN 有数据进线，目前单个 VDN 上最大排队数 N，各地在压测阶段达到单技能最大排队数 N。机票 VDN 对应南通和上海两地有两个 VDN 有数据进线，南通机票 VDN 最大排队数为 M，压测阶段也达到单技能最大排队数；上海机票 VDN 因为人数少，根据 EWT 计算，所以进线压测阶段进线量很少，不会达到限流值的数量，如图 2-3。故该场景符合预期。

2-3 排队情况

• 正常 IVR 满后，分配到溢出 IVR 的场景

上海和南通正常 IVR 限流 W, 上海和南通各 2 台，正常 IVR 限流满 W*4，进入溢出 IVR，溢出 IVR 上海和南通各 2 台，每台限流 Q，溢出 IVR 也打满。服务器性能如图 2-4，故该场景符合预期。

2-4 正常 IVR 服务器

• 正常 IVR 和溢出 IVR 全部满之后，电话无法呼入到 IVR 的场景

当溢出 IVR 到达限流，此时拨打电话无法接通，服务器性能如图 2-5。故该场景符合预期。

2-5 溢出 IVR 服务器

• PBX 的异地分配准确性

两个异地分配的技能组登录坐席情况如下：

执行压测过程中观察分配情况，抽查其中的分配日志，上图的技能组对应的 VDN 的 EWT 计算（input route vdn:252820; luodivdn:252701; EWT:8635; input route vdn: 252820; luodivdn:252705; EWT:222）以及数据库中查询该通话的最后分配坐席，&ewt=routevdn=252820&luodivdn=252705&weight=222，确认该通电话的分配正确性。

压测期间，ACD 分配机服务器性能如图 2-6。该场景符合预期。

2-6 分配机服务器

三、小结

当系统的流程和实现方式改变，在功能实现完成并且系统测试相对稳定后，进行性能测试是项目上线前的一颗定心丸，跟着系统的发布节奏进行不定期的压力测试显得非常重要。

整个压测过程看出，各个服务器的使用百分比都不高，由此可见，携程的电话系统所支持的并发能力还有很大的流量扩展空间。此次达到压测前设定的最大并发通话，为现有系统压力的多倍，用设置的限流值来测试系统的的保底机制和分配服务。随着携程业务的开创和发展，相信携程电话系统可以迎接携程高质量和全球化战略带来的更大流量的挑战。

作者介绍：

Mario ，携程资深测试工程师，负责携程呼叫中心测试。