HTTP異步接口性能測試方案設(shè)計與實踐

孫 立 哲

(公安部第三研究所eID事業(yè)部 上海 201204)

0 引 言

隨著計算機(jī)網(wǎng)絡(luò)的快速發(fā)展，網(wǎng)絡(luò)用戶數(shù)增多，并發(fā)訪問量加大，分布式應(yīng)用系統(tǒng)在高并發(fā)可用性方面面臨巨大的挑戰(zhàn)。為了提高系統(tǒng)的高并發(fā)性能，分布式應(yīng)用系統(tǒng)內(nèi)部設(shè)計多采用異步處理模式。隨著互聯(lián)網(wǎng)應(yīng)用技術(shù)復(fù)雜性不斷提高，高效的測試技術(shù)和工具逐漸成為高質(zhì)量應(yīng)用的必要保證。

HTTP接口即基于HTTP協(xié)議、可遠(yuǎn)程訪問的接口，是分布式應(yīng)用系統(tǒng)[1]的一種技術(shù)實現(xiàn)。HTTP協(xié)議是互聯(lián)網(wǎng)上客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議[2]。接口是預(yù)先定義的函數(shù)，旨在提供應(yīng)用程序與開發(fā)人員基于某軟件或硬件得以訪問一組例程的能力。接口內(nèi)部實現(xiàn)對特定業(yè)務(wù)處理邏輯的封裝，接口調(diào)用方只需按接口調(diào)用規(guī)則進(jìn)行訪問即可完成特定業(yè)務(wù)的處理，無需關(guān)注內(nèi)部實現(xiàn)細(xì)節(jié)。

根據(jù)接口內(nèi)部業(yè)務(wù)處理模式不同，HTTP接口可分為同步接口和異步接口。同步接口是指請求方以HTTP請求方式訪問服務(wù)端HTTP接口，接口收到請求并完成全部業(yè)務(wù)處理后將結(jié)果以HTTP響應(yīng)方式直接返回給請求方。異步接口是指請求方以HTTP請求方式訪問服務(wù)端HTTP異步接口，請求參數(shù)中需包含一個用于接收異步處理結(jié)果的HTTP回調(diào)接口地址，接口收到請求并在完成部分業(yè)務(wù)處理后以HTTP響應(yīng)方式將處理結(jié)果返回給請求方(即同步返回)，或者不做任何業(yè)務(wù)處理直接以HTTP響應(yīng)方式返回一定數(shù)據(jù)以告知請求已收到，之后HTTP接口內(nèi)部再啟動新線程處理后續(xù)業(yè)務(wù)并訪問請求方提供的回調(diào)接口將結(jié)果發(fā)給請求方(即異步返回)。HTTP異步接口業(yè)務(wù)流程圖如圖1所示。

圖1 HTTP異步接口的業(yè)務(wù)處理流程圖

JMeter[3]是Apache組織開發(fā)的基于Java的壓力測試工具，以其開源、小巧以及功能強(qiáng)大等優(yōu)勢而備受青睞[4]。它可用于對服務(wù)器、網(wǎng)絡(luò)或?qū)ο竽M巨大的負(fù)載，在不同壓力類別下測試它們的強(qiáng)度及分析整體性能。JMeter支持對Web服務(wù)HTTP接口的性能壓測[5]，但其在HTTP異步接口的性能壓測方面存在一定的局限性。JMeter對HTTP接口的壓測只能覆蓋到同步接口和異步接口的同步處理邏輯，無法覆蓋到異步接口內(nèi)部的異步處理邏輯。單獨使用JMeter對HTTP異步接口進(jìn)行的性能壓測不能覆蓋接口內(nèi)部完整業(yè)務(wù)處理邏輯，因此JMeter的壓測結(jié)果不能反映出接口自身的真實性能情況。

本文根據(jù)HTTP異步接口內(nèi)部業(yè)務(wù)實現(xiàn)特性，結(jié)合JMeter支持純Java腳本編寫的特點，設(shè)計了一套集JMeter工具、MySQL數(shù)據(jù)庫表設(shè)計[6]、模擬接口測試樁設(shè)計以及自定義Java腳本設(shè)計等為一體的性能測試方案。該方案能夠覆蓋HTTP異步接口完整業(yè)務(wù)處理邏輯，且通過在真實產(chǎn)品中進(jìn)行性能壓測實踐，證明了該方案的可行性與實效性，彌補(bǔ)了JMeter在異步接口性能壓測中所表現(xiàn)出的不足。

1 性能測試方案設(shè)計與實現(xiàn)

性能測試方案的整體思路及具體實現(xiàn)按整個壓測過程可分為壓測前準(zhǔn)備、JMeter壓測與數(shù)據(jù)收集以及結(jié)果統(tǒng)計分析三部分。

1.1 壓測前準(zhǔn)備

本性能測試方案所需測試環(huán)境主要涉及JMeter客戶機(jī)、被壓測接口所在服務(wù)器、模擬回調(diào)接口測試樁所在JBoss服務(wù)器、MySQL數(shù)據(jù)庫服務(wù)器。性能測試環(huán)境整體架構(gòu)如圖2所示。

圖2 性能測試環(huán)境整體架構(gòu)圖

壓測前準(zhǔn)備主要完成MySQL數(shù)據(jù)庫服務(wù)搭建與數(shù)據(jù)庫表設(shè)計、模擬接口調(diào)用方的HTTP回調(diào)接口測試樁設(shè)計與實現(xiàn)及基于JBoss服務(wù)的部署、被壓測接口作特定處理，以及各服務(wù)器和JMeter所在客戶機(jī)環(huán)境性能調(diào)優(yōu)。

搭建MySQL服務(wù)器，創(chuàng)建數(shù)據(jù)庫，設(shè)計數(shù)據(jù)表[7]。針對單級HTTP異步接口，即接口內(nèi)部不調(diào)用其他異步接口，只需設(shè)計兩個數(shù)據(jù)表即可。一個為請求表，用于記錄被壓測HTTP接口收到的請求數(shù)據(jù)，一個為響應(yīng)表，用于記錄被壓測接口異步響應(yīng)數(shù)據(jù)。表字段設(shè)計分別見表1和表2。

表1 請求表

表2 響應(yīng)表

針對二級HTTP異步接口，即接口內(nèi)部又調(diào)用其他異步接口，需作擴(kuò)展設(shè)計，即設(shè)計四個數(shù)據(jù)表。其中：三個請求表依次分別記錄被壓測HTTP接口收到的請求數(shù)據(jù)、被壓測接口內(nèi)部調(diào)用其他異步接口時下發(fā)的HTTP請求數(shù)據(jù)、被壓測接口的回調(diào)接口收到的HTTP請求數(shù)據(jù)；一個響應(yīng)表記錄被壓測接口的回調(diào)接口返回的異步響應(yīng)數(shù)據(jù)。針對多級HTTP異步接口，可按上述邏輯繼續(xù)作擴(kuò)展設(shè)計。

被壓測接口在接口內(nèi)部增加兩部分特定業(yè)務(wù)處理。一是在請求處理開始之前將請求串插入MySQL庫請求表，二是將異步返回的響應(yīng)數(shù)據(jù)按要求插入MySQL庫響應(yīng)表。增加特定業(yè)務(wù)處理后的流程圖如圖3所示。

圖3 HTTP異步接口性能測試特有業(yè)務(wù)流程圖

搭建JBoss服務(wù)器，使用Java腳本基于Web Servlet技術(shù)[8]開發(fā)模擬請求方的HTTP回調(diào)接口的測試樁并打包成Web存檔文件部署在JBoss服務(wù)上。測試樁接口內(nèi)部業(yè)務(wù)邏輯為接收被壓測接口異步返回的數(shù)據(jù)并按預(yù)定要求作出響應(yīng)。為確保各服務(wù)器之間有良好的通信性能，需設(shè)定各測試用服務(wù)器在硬件與操作系統(tǒng)等配置方面與被壓測接口所在服務(wù)器保持一致，MySQL數(shù)據(jù)庫服務(wù)和JBoss服務(wù)在線程池、日志等級等方面作性能最優(yōu)配置。整套測試環(huán)境在同一局域網(wǎng)內(nèi)。

1.2 JMeter壓測與數(shù)據(jù)收集

使用JMeter合理設(shè)計測試計劃，對HTTP異步接口進(jìn)行壓測并在壓測過程中收集接口請求數(shù)據(jù)和異步返回的響應(yīng)數(shù)據(jù)：1) 在JMeter測試計劃中，針對被壓測接口新建一線程組，在線程組中添加取樣器“HTTP請求”，并配置接口請求地址、請求方式及請求參數(shù)等數(shù)據(jù)。2) 使用JMeter配置元件“用戶定義的變量”定義請求串中可配且有可能需手動調(diào)整的參數(shù)，如數(shù)據(jù)庫配置信息等。使用JMeter配置元件“CSV Data Set Config”讀取需要從數(shù)據(jù)庫中提取的批量測試數(shù)據(jù)，在此之前需編寫自定義Java腳本實現(xiàn)從數(shù)據(jù)庫中提取批量數(shù)據(jù)并生成測試所需逗號分隔值(Comma-Separated Values，CSV)數(shù)據(jù)文件。3) 在JMeter前置處理器“BeanShell PreProcessor”中編寫Java腳本，調(diào)用事先用Java腳本編寫并打包好的自定義Jar包，實現(xiàn)對請求參數(shù)的特定處理，如對某請求參數(shù)數(shù)據(jù)加密或作簽名等。4) 使用JMeter斷言“響應(yīng)斷言”判斷被壓測接口同步返回的響應(yīng)數(shù)據(jù)是否正確。5) 使用JMeter監(jiān)聽器“察看結(jié)果樹”檢查短時間高并發(fā)下異常信息，在長時間高并發(fā)下需禁用“察看結(jié)果樹”以確保JMeter自身性能良好。6) 使用JMeter監(jiān)聽器“聚合報告”記錄并顯示壓測結(jié)果。

根據(jù)實際性能需求，在線程組的線程屬性和調(diào)度器配置中分別配置并發(fā)用戶數(shù)和壓測持續(xù)時間，啟動JMeter壓測。JMeter壓測過程中，將被壓測接口的請求數(shù)據(jù)和異步返回的響應(yīng)數(shù)據(jù)分別插入MySQL數(shù)據(jù)庫請求表和響應(yīng)表中。

1.3 結(jié)果統(tǒng)計分析

對JMeter壓測結(jié)果以及壓測過程中收集的請求數(shù)據(jù)和響應(yīng)數(shù)據(jù)作統(tǒng)計分析：1) 通過分析JMeter聚合報告結(jié)果，可評估異步接口中同步處理業(yè)務(wù)的性能。2) 采用自定義Java腳本對MySQL庫請求表和響應(yīng)表中的數(shù)據(jù)作統(tǒng)計分析，評估HTTP異步接口內(nèi)部完整業(yè)務(wù)的性能。

具體分析步驟：1) 比對請求表中記錄數(shù)和響應(yīng)表中記錄數(shù)是否一致，若不一致，則說明有失敗的請求，若一致則繼續(xù)后續(xù)比對分析。2) 逐條讀取請求表中的記錄，根據(jù)業(yè)務(wù)流水號字段值到響應(yīng)表中去查找對應(yīng)記錄。若能找到，則繼續(xù)檢查響應(yīng)數(shù)據(jù)是否正確，若正確則本次HTTP請求處理成功，若不正確則本次請求失敗。若根據(jù)業(yè)務(wù)流水號未能在響應(yīng)表中查找到對應(yīng)記錄，則本次HTTP請求失敗。3) 在逐條讀取請求表中記錄并作比對分析的過程中，統(tǒng)計記錄HTTP請求成功總數(shù)和失敗總數(shù)。若HTTP請求成功總數(shù)與請求表中記錄總數(shù)相等，則說明HTTP異步接口在高并發(fā)壓力下均能成功處理各HTTP請求。若不等，用請求失敗總數(shù)除以總請求數(shù)得到出錯率。4) 針對請求成功的記錄，根據(jù)響應(yīng)表中記錄的業(yè)務(wù)處理時間與請求表中對應(yīng)記錄的業(yè)務(wù)處理時間計算本次HTTP請求的處理耗時。統(tǒng)計所有成功的請求中的最大響應(yīng)耗時、最小響應(yīng)耗時和平均響應(yīng)耗時。

2 二級異步調(diào)用接口性能壓測擴(kuò)展實踐

2.1 二級異步調(diào)用接口實例

某身份標(biāo)識產(chǎn)品對外提供的短信服務(wù)(Short Messaging Service，SMS)簽名接口是一個復(fù)雜的二級異步調(diào)用接口，其向第三方服務(wù)提供的回調(diào)接口也是異步接口。SMS簽名接口及其回調(diào)接口相關(guān)的完整業(yè)務(wù)流程如圖4所示。

圖4 SMS簽名接口完整業(yè)務(wù)處理流程圖

SMS簽名業(yè)務(wù)完整處理邏輯分兩個階段，第一階段為從請求方向SMS簽名接口發(fā)送請求開始到SMS簽名接口向第三方服務(wù)下發(fā)短信下行(以下簡稱“MT”)請求為止，第二階段為從第三方服務(wù)向MO回調(diào)接口發(fā)送請求開始到短信上行(以下簡稱“MO”)回調(diào)接口向請求方發(fā)送異步處理結(jié)果為止。

2.2 性能測試方案擴(kuò)展實現(xiàn)

根據(jù)性能測試方案中所述針對二級異步調(diào)用接口的數(shù)據(jù)庫表設(shè)計方法，在MySQL數(shù)據(jù)庫中新建四個表，分別為SMS簽名請求表、SMS簽名短信下行請求表、SMS簽名短信上行請求表、SMS簽名響應(yīng)表。各請求表字段同表1，響應(yīng)表字段同表2，四個表中的記錄通過業(yè)務(wù)流水號字段唯一關(guān)聯(lián)。SMS簽名請求表記錄SMS簽名接口的HTTP請求數(shù)據(jù)，SMS簽名短信下行請求表記錄SMS簽名接口內(nèi)部下發(fā)的MT請求數(shù)據(jù)，SMS簽名短信上行請求表記錄MO回調(diào)接口的HTTP請求數(shù)據(jù)，SMS簽名響應(yīng)表記錄MO回調(diào)接口內(nèi)部下發(fā)的SMS簽名回調(diào)請求數(shù)據(jù)，即SMS簽名接口返回的異步響應(yīng)數(shù)據(jù)。SMS簽名請求表和SMS簽名短信上行請求表可由被壓測接口進(jìn)行數(shù)據(jù)插入，也可由請求發(fā)起方進(jìn)行數(shù)據(jù)插入。由請求發(fā)起方進(jìn)行數(shù)據(jù)插入，可將請求發(fā)起方與被壓測接口之間的網(wǎng)絡(luò)傳輸、Web服務(wù)等相關(guān)環(huán)境性能情況涵蓋在內(nèi)，得出的性能評估結(jié)果也更全面，因此，本文采取由請求發(fā)起方進(jìn)行數(shù)據(jù)插入的方式。被壓測的SMS簽名接口和MO回調(diào)接口內(nèi)部分別增加特定處理邏輯，即SMS簽名接口中在下發(fā)MT消息前將即將下發(fā)的MT請求數(shù)據(jù)插入SMS簽名短信下行請求表，MO回調(diào)接口中在下發(fā)HTTP請求給請求方回調(diào)接口前將HTTP請求數(shù)據(jù)插入SMS簽名響應(yīng)表。按請求方回調(diào)接口規(guī)則開發(fā)模擬測試樁供MO回調(diào)接口調(diào)用。

由于SMS簽名接口是二級異步調(diào)用接口，業(yè)務(wù)邏輯較復(fù)雜，因此，需要在前述性能測試方案基礎(chǔ)上做一定的延伸擴(kuò)展。在同一個測試計劃的同一個線程組內(nèi)創(chuàng)建兩個HTTP請求取樣器，分別對應(yīng)SMS簽名接口和MO回調(diào)接口。SMS簽名接口取樣器內(nèi)部的BeanShell前置處理器腳本中需增加將HTTP請求數(shù)據(jù)插入SMS簽名請求表。MO回調(diào)接口取樣器內(nèi)部的BeanShell前置處理器腳本中需增加將HTTP請求數(shù)據(jù)插入SMS簽名短信上行請求表。編寫Java腳本用軟實現(xiàn)方式模擬終端內(nèi)部處理邏輯生成簽名值并組裝成MO回調(diào)接口請求數(shù)據(jù)，以Jar包的形式供JMeter調(diào)用?；贛O回調(diào)接口內(nèi)部有對MO消息與MT消息的數(shù)據(jù)關(guān)聯(lián)檢查，在MO回調(diào)接口前置處理器腳本中還需增加一層邏輯處理，即只有在SMS簽名短信下行請求表中查找到對應(yīng)的記錄后才下發(fā)MO回調(diào)請求。根據(jù)產(chǎn)品實際性能需求，配置200個并發(fā)用戶數(shù)，循環(huán)100次，執(zhí)行JMeter壓測。

采用性能測試方案中所述結(jié)果統(tǒng)計分析方法，對在壓測過程中插入MySQL數(shù)據(jù)庫四個表中的數(shù)據(jù)做擴(kuò)展性統(tǒng)計分析，評估SMS簽名接口和MO回調(diào)接口內(nèi)部完整業(yè)務(wù)邏輯性能情況。編寫自定義Java腳本，逐一提取SMS簽名請求表中記錄，在SMS簽名響應(yīng)表中進(jìn)行查找，檢查是否有對應(yīng)的響應(yīng)串并對響應(yīng)串?dāng)?shù)據(jù)正確性作判斷。對于能找到對應(yīng)響應(yīng)串且響應(yīng)串?dāng)?shù)據(jù)正確的記為請求成功，對于未找到或者找到但相應(yīng)數(shù)據(jù)不正確者記為請求失敗，記錄請求成功總數(shù)和失敗總數(shù)。對于請求成功的記錄，根據(jù)SMS簽名請求表和SMS簽名短信下行請求表中的業(yè)務(wù)處理時間字段數(shù)據(jù)，按前述統(tǒng)計方式統(tǒng)計第一階段SMS簽名接口內(nèi)部完整業(yè)務(wù)邏輯處理平均耗時，根據(jù)SMS簽名短信上行請求表和SMS簽名響應(yīng)表中的業(yè)務(wù)處理時間字段數(shù)據(jù)，統(tǒng)計第二階段MO回調(diào)接口內(nèi)部完整業(yè)務(wù)邏輯處理平均耗時，記錄第一階段耗時、第二階段耗時以及兩個階段的總耗時，統(tǒng)計分析所有請求成功的記錄的平均響應(yīng)耗時、最大響應(yīng)耗時和最小響應(yīng)耗時。對于請求失敗的記錄，記錄相應(yīng)的業(yè)務(wù)流水號，便于作后續(xù)的問題排查分析。以上統(tǒng)計所得數(shù)據(jù)全部記入文件備查。

2.3 壓測結(jié)果分析

壓測生成的JMeter聚合報告顯示：SMS簽名接口總請求數(shù)為20 000，內(nèi)部同步處理邏輯平均響應(yīng)耗時為297毫秒，最小響應(yīng)耗時為48毫秒，出錯率為0.00%；MO回調(diào)接口總請求數(shù)為20 000，內(nèi)部同步處理邏輯平均響應(yīng)耗時為1 267毫秒，最小響應(yīng)耗時為90毫秒，出錯率為0.00%。兩個接口內(nèi)部同步處理邏輯性能尚在可接受范圍內(nèi)。

對JMeter壓測過程中插入數(shù)據(jù)庫表中的各請求數(shù)據(jù)和響應(yīng)數(shù)據(jù)作統(tǒng)計分析。JMeter發(fā)給SMS簽名接口的總請求數(shù)為20 000，發(fā)給MO回調(diào)接口的總請求數(shù)為20 000。異步收到結(jié)果的總記錄數(shù)為20 000，且所有記錄的響應(yīng)數(shù)據(jù)均正確。其中，能與請求相關(guān)聯(lián)的有19 896條記錄，無法關(guān)聯(lián)的有104條。能與請求相關(guān)聯(lián)的所有記錄中，最小響應(yīng)耗時50 394毫秒，最大響應(yīng)耗時56 522毫秒，平均響應(yīng)耗時51 270毫秒。

對結(jié)果作進(jìn)一步分析，從發(fā)給MO回調(diào)接口的總請求數(shù)以及接口對應(yīng)的后臺日志可以確認(rèn)，MO回調(diào)接口的20 000次請求中有104次未能成功返回異步結(jié)果，錯誤率為0.52%。通過比對JMeter發(fā)出請求的時間與接口對應(yīng)后臺日志中顯示的收到HTTP請求的時間，發(fā)現(xiàn)服務(wù)端接口收到請求的時間比JMeter發(fā)出請求的時間滯后約25秒。統(tǒng)計分析生成的部分結(jié)果示例如圖5所示。

圖5 統(tǒng)計分析生成的部分結(jié)果示例

綜上，基于本文提出的性能測試方案，不僅使用JMeter完成了對SMS簽名異步接口和MO回調(diào)異步接口內(nèi)部的同步業(yè)務(wù)邏輯的性能評測，還根據(jù)壓測過程中收集的數(shù)據(jù)及對數(shù)據(jù)的統(tǒng)計分析完成了對兩個異步接口內(nèi)完整業(yè)務(wù)邏輯的性能評測，發(fā)現(xiàn)了僅僅使用JMeter壓測無法檢出的兩個性能問題。實踐證明，本文所描述的性能測試方案切實可行且有明顯實效。

3 結(jié) 語

本文結(jié)合異步接口內(nèi)部處理邏輯，從分層壓測和統(tǒng)計分析的角度出發(fā)，整合JMeter性能測試計劃設(shè)計、MySQL數(shù)據(jù)庫表設(shè)計、模擬接口測試樁設(shè)計和自定義Java腳本設(shè)計等多方面的技術(shù)，設(shè)計了一套能夠覆蓋HTTP異步接口內(nèi)部完整處理邏輯的性能測試方案。通過在真實產(chǎn)品中進(jìn)行性能壓測實踐，證明了該方案在HTTP異步接口性能評測方面的可行性與實效性?；诜謱訅簻y和統(tǒng)計分析的特性，該方案具有良好的可擴(kuò)展性，不僅適用于具有二級異步調(diào)用關(guān)系的接口性能評測，也可以通過延伸擴(kuò)展應(yīng)用于具有多級異步調(diào)用關(guān)系的復(fù)雜接口性能評測。