天天看點

幹貨 | 每天上百萬通話,攜程電話系統性能測試實踐一、背景 二、性能測試開展 三、小結

作者簡介

Mario ,攜程資深測試工程師,負責攜程呼叫中心測試。

一、背景

作為全球領先的線上旅遊企業,攜程注重服務品質,并擁有全球最大的旅遊呼叫中心,分别部署在國内自建系統、國内和國外第三方雲服務平台上。呼叫中心每天承接着上百萬通的通話,電話服務系統是整個呼叫中心中非常重要的一套系統,服務着數萬客服座席,系統的穩定性至關重要。

二、性能測試開展

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)進行異地配置設定,在高并發場景驗證系統的配置設定準确性。

壓測伺服器配置如下:

IVR SM PBX(ACD)
上海4台,南通4台 1台 上海1台,南通1台

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 配置設定機伺服器

三、小結

當系統的流程和實作方式改變,在功能實作完成并且系統測試相對穩定後,進行性能測試是項目上線前的一顆定心丸,跟着系統的釋出節奏進行不定期的壓力測試顯得非常重要。

整個壓測過程看出,各個伺服器的使用百分比都不高,由此可見,攜程的電話系統所支援的并發能力還有很大的流量擴充空間。此次達到壓測前設定的最大并發通話,為現有系統壓力的多倍,用設定的限流值來測試系統的的保底機制和配置設定服務。随着攜程業務的開創和發展,相信攜程電話系統可以迎接攜程高品質和全球化戰略帶來的更大流量的挑戰。