優(yōu)質(zhì)文章，第一時間送達！
各位好，我叫王捷豪，在測試行業(yè)已經(jīng)有7年，曾從事過酒店、空氣質(zhì)量、電網(wǎng)領(lǐng)域，目前是國內(nèi)某互聯(lián)網(wǎng)醫(yī)療公司研發(fā)中心基礎(chǔ)平臺部一名測試開發(fā)工程師，多年的測試工作對測試知識有一些小認識，希望通過該篇文章與各位分享關(guān)于如何開展不同測試類型的性能測試，以及性能測試環(huán)節(jié)中遇到的一些問題與解決方案。本次性能測試是針對集成服務(wù)開展的一系列性能測試，其中性能測試范圍包括基準測試、配置&定容定量測試。
內(nèi)有干貨，篇符較長，請耐心品完
集成服務(wù)（Integration Services）是用于生成高性能數(shù)據(jù)集成和工作流，包括針對數(shù)據(jù)源數(shù)據(jù)的提取、轉(zhuǎn)換和加載等操作的解決方案，主要解決眾多系統(tǒng)情況下，不同系統(tǒng)之間點對點通信需要開發(fā)新接口問題。因此，通過搭建統(tǒng)一規(guī)范、統(tǒng)一代碼、統(tǒng)一接口的信息集成平臺，以集成服務(wù)為中介，實現(xiàn)各系統(tǒng)間的信息共享和交互。
下圖是基于集成服務(wù)部署的一個數(shù)據(jù)同步集成方案，該集成方案通過獲取數(shù)據(jù)源數(shù)據(jù)，并按照映射關(guān)系轉(zhuǎn)化數(shù)據(jù)，同步至目標數(shù)據(jù)庫，集成方案具體操作有以下幾點：
通過日志輪詢JDBC連接數(shù)據(jù)庫，按照設(shè)定的時間間隔，定時查詢?nèi)蝿?wù)日志表多條日志數(shù)據(jù)，返回日志數(shù)據(jù)所關(guān)聯(lián)的業(yè)務(wù)數(shù)據(jù)
通過分支節(jié)點修改發(fā)送次數(shù)，記錄操作次數(shù)，當操作次數(shù)超出3次，日志仍處于同步失敗狀態(tài)，則不再同步該條日志的業(yè)務(wù)數(shù)據(jù)
通過映射處理器轉(zhuǎn)換數(shù)據(jù)，并保存數(shù)據(jù)至目標數(shù)據(jù)庫，同時修改日志表日志狀態(tài)為成功
在性能測試過程中，了解服務(wù)的系統(tǒng)架構(gòu)圖能夠更清楚性能壓力在哪個環(huán)節(jié)上，如在集成服務(wù)同步數(shù)據(jù)過程中，可以對數(shù)據(jù)庫、集成服務(wù)、中間件、日志服務(wù)器等節(jié)點進行監(jiān)控。
在開展性能測試前，通常情況下需要選擇性能測試工具對接口進行多并發(fā)施壓，如主流的性能工具LoadRunner、JMeter，但實際上壓測對象不一定是可見的接口。對于本次分享的集成服務(wù)，其原理是通過設(shè)置的定時器按照最快秒級頻率觸發(fā)一次同步任務(wù)，其壓力不在接口并發(fā)數(shù)量上，而是在調(diào)度頻率、同步數(shù)據(jù)量大小上，因此無法借助性能工具進行壓測。
基準測試（benchmarking）是在某個時間點通過基準測試建立一個已知的性能水平線（稱為基準線），當系統(tǒng)的軟硬件環(huán)境發(fā)生變化之后，通過再次基準測試建立新基準線，對新舊基準線進行比較，以確定哪些變化對性能的影響。
在進行基準測試前，需制定相應(yīng)測試計劃，確定測試目的、測試范圍、測試環(huán)境、集成方案、測試準備內(nèi)容、測試用例等內(nèi)容。
在測試范圍上，挑選了兩個業(yè)務(wù)場景（見下方表格），其中注冊場景，其視圖關(guān)聯(lián)表數(shù)據(jù)復(fù)雜程度低；而登記場景，其視圖關(guān)聯(lián)表數(shù)據(jù)復(fù)雜程度相對注冊場景高，且關(guān)聯(lián)表字段有BLOB類型字段，該字段可以存儲二進制文件。這兩個場景的區(qū)別在查詢一條數(shù)據(jù)時，數(shù)據(jù)大小和關(guān)聯(lián)復(fù)雜程度。
在部署測試集成方案時，通過和現(xiàn)場開發(fā)人員、產(chǎn)品經(jīng)理多次確認生產(chǎn)實際部署方案，目的是為了盡可能貼近現(xiàn)場方案。由于性能測試開展在現(xiàn)場部署之前，最終測試集成方案（見下方第一張圖）和生產(chǎn)集成方案上存在一定區(qū)別（見下方第二張圖），這與前期評估不夠精準以及現(xiàn)場人員對業(yè)務(wù)需求進一步了解后發(fā)生的變更有關(guān)系。
在測試準備內(nèi)容方面，除了部署集成方案，需按照場景分別制造測試數(shù)據(jù)，了解表與表之間的關(guān)聯(lián)關(guān)系，此次批量制造日志表1w條數(shù)據(jù)，視圖表數(shù)據(jù)10w至20w數(shù)據(jù)。
#批量制造數(shù)據(jù)SQL
BEGIN
for i in 1 .. 100000 loop
#插入SQL
INSERT INTO INSERT INTO "庫名"."表名" (字段名,關(guān)聯(lián)id字段名) VALUES ('字段值', i);
end loop;
commit;
END;
在基準測試用例方面，挑選了調(diào)度頻率、日志輪詢查詢條數(shù)、數(shù)據(jù)大小、日志表數(shù)據(jù)量、視圖表數(shù)據(jù)量五個變量進行測試，通過五個變量采集同步數(shù)據(jù)總耗時、每秒可同步條數(shù)、實際調(diào)度頻率結(jié)果，最終找出最佳方案設(shè)置下最佳基準線。同時，對每個變量設(shè)定中值線（下表調(diào)度頻率變量3秒每次），在中值線基礎(chǔ)上設(shè)置下限值（下表調(diào)度頻率變量1秒每次）和上限制（下表調(diào)度頻率變量5秒每次），其中中值線通過和現(xiàn)場開發(fā)人員、產(chǎn)品經(jīng)理溝通確定，測試過程中會發(fā)現(xiàn)確定的中值線不一定準確，因此需要額外場景測試找到中值線。
問題1：制造10w數(shù)據(jù)的時候，插入數(shù)據(jù)失敗，提示unable to extend lob segment by 128 xxxx in tablespace xxxx
解決方案：找DBA增加表空間
問題2：基準測試開展前，由于集成方案保存數(shù)據(jù)接口通過其它產(chǎn)品線開發(fā)人員配置，因此需要產(chǎn)品線和產(chǎn)品線之間開發(fā)人員的配合，但實際還面臨其它產(chǎn)品線開發(fā)人員去了現(xiàn)場或是有其它緊急任務(wù)，導(dǎo)致基準測試進度無法推進
解決方案：創(chuàng)建一個性能測試專項群，把產(chǎn)品經(jīng)理、開發(fā)人員、測試人員拉進去，通過產(chǎn)品經(jīng)理推動性能測試進度，同時根據(jù)任務(wù)優(yōu)先級安排時間和工作，如開發(fā)人員現(xiàn)場任務(wù)緊急，測試人員可以準備測數(shù)據(jù)以及設(shè)計測試用例等其它工作
問題3：采集結(jié)果波動大，如上方表格場景編號1-1測試用例，1w條日志同步完總耗時可能偏差10多秒，是因為測試環(huán)境不只是一個用戶使用，而且部署了非當前性能測試其它服務(wù)
解決方案：最好的方式是部署獨立的測試環(huán)境，但實際上部署成本高以及設(shè)備資源少，只能協(xié)調(diào)或避開測試環(huán)境多用戶使用高峰期，或者對場景進行多次采集，剔除異常數(shù)據(jù)之后求均值
問題4：集成方案調(diào)度任務(wù)狀態(tài)出現(xiàn)長時間處于執(zhí)行中，或是集成服務(wù)出現(xiàn)崩潰，由于集成服務(wù)內(nèi)存分配了512M，而JDBC節(jié)點查詢數(shù)據(jù)時主要消耗內(nèi)存資源，導(dǎo)致JVM頻繁GC
解決方案：集成服務(wù)調(diào)整內(nèi)存分配至1G，同時限制JDBC節(jié)點查詢數(shù)據(jù)量以及降低調(diào)度頻率
配置測試：通過對被測試軟件的軟硬件配置進行測試，找到系統(tǒng)各項資源的最優(yōu)分配原則。配置測試能充分利用有限的軟硬件資源，發(fā)揮系統(tǒng)的最佳處理能力，同時可以將其與其它性能測試類型聯(lián)合應(yīng)用，從而為系統(tǒng)提供重要依據(jù)。
定容定量測試：在一定的軟硬件條件下，在數(shù)據(jù)庫中構(gòu)造不同數(shù)量級的記錄數(shù)量，通過運行一種或多種業(yè)務(wù)場景在一定虛擬用戶數(shù)量的情況下，獲取不同數(shù)量級別的性能指標，從而得到在該數(shù)量級下系統(tǒng)能夠處理的最大會話能力、最大容量等。
與基準測試5.1工作開展過程不同的是，配置&定容定量測試調(diào)整了場景用例和增加了監(jiān)控。
在測試用例設(shè)計上，選擇了注冊場景、更新場景作為相同場景，用于測試多節(jié)點場景。另選擇登記場景作為定容定量場景，通過更改BLOB文件大小控制數(shù)據(jù)量級。
在選擇性能監(jiān)控平臺上，數(shù)據(jù)庫監(jiān)控通過Grafana平臺，主機監(jiān)控由于公司沒有統(tǒng)一的監(jiān)控平臺，因此主機監(jiān)控通過多個平臺配合監(jiān)控，包括Grafana、VMware vSphere、linux命令、Spring Boot Admin。
在開始配置測試前，由于需要更改CPU、內(nèi)存、磁盤等資源，因此需要運維工程師協(xié)助驅(qū)散集成服務(wù)所在節(jié)點，禁止別的容器調(diào)度節(jié)點，同時需要系統(tǒng)工程師協(xié)助調(diào)整主機CPU和磁盤資源大小，再由測試工程師自行重啟集成服務(wù)，調(diào)整服務(wù)使用內(nèi)存大小。由于啟動集成服務(wù)至少需要內(nèi)存 500M、磁盤 100G、CPU 4核，否則較易出現(xiàn)服務(wù)崩潰或啟動服務(wù)失敗，因此以該配置做為最低配置。
在配置過程中，通過更改CPU核數(shù)發(fā)現(xiàn)，當CPU4核時，CPU使用率70%左右。同時，CPU核數(shù)對數(shù)據(jù)同步速度影響不大，每秒同步條數(shù)相差不大。
通過更改內(nèi)存發(fā)現(xiàn)，當內(nèi)存大小足以緩存低數(shù)量級數(shù)據(jù)時，內(nèi)存大小對同步數(shù)據(jù)速度影響不大，每秒同步條數(shù)相差不大。
但當數(shù)據(jù)的數(shù)據(jù)量級發(fā)生變更，數(shù)據(jù)量級逐漸增大時，內(nèi)存回收速度逐漸變快，一開始呈規(guī)律性回收（下方第一二張圖），最后呈非規(guī)律性回收（下方第三張圖）。
通過配置測試結(jié)果也可知，當數(shù)據(jù)量級增大時，內(nèi)存消耗增大，集成服務(wù)同步速度下降。
問題1：在配置測試過程中，再次出現(xiàn)采集數(shù)據(jù)波動較大，后來發(fā)現(xiàn)是數(shù)據(jù)保存接口所在服務(wù)器磁盤問題等待時間過長導(dǎo)致
解決方案：更換主機磁盤
問題2：在測試過程中，出現(xiàn)磁盤不足，當前配置磁盤大小100G，而日志會記錄各個節(jié)點處理日志，包括打印出SQL查詢的數(shù)據(jù)，并且沒有定時清理日志
解決方案：日志只截取部分SQL查詢出來的數(shù)據(jù)，減少日志內(nèi)容，同時只保留固定天數(shù)日志，備份日志到其它磁盤空間
問題3：在同步數(shù)據(jù)過程中，出現(xiàn)同步數(shù)據(jù)失敗，后來發(fā)現(xiàn)是數(shù)據(jù)庫緩存表不足導(dǎo)致，數(shù)據(jù)庫關(guān)聯(lián)查詢數(shù)據(jù)或者排序時會使用到臨時表
解決方案：增加臨時表空間或者降低數(shù)據(jù)庫操作頻率，讓緩存表數(shù)據(jù)能夠有時間釋放
看過性能測試相關(guān)文章或者是開展過性能測試的小伙伴應(yīng)該有體會， 性能測試不只是某一個人的事，也不只是測試部門的事，而是一個需要多角色人員參與和積極配合的性能團隊。如果只有測試工程師一個角色人員或者其它角色人員不積極配合，性能測試工作都無法順利推進。在本次性能測試過程中，參與進性能測試工作的角色包含了DBA、運維開發(fā)工程師、系統(tǒng)工程師、測試工程師、開發(fā)工程師、產(chǎn)品經(jīng)理、需求人員。同時，測試工程師在性能測試過程中，不只是對測試對象進行性能測試，更充當了協(xié)調(diào)配合和推進性能測試的角色。在專業(yè)技能上，測試工程師需要對系統(tǒng)架構(gòu)、功能邏輯、性能知識、數(shù)據(jù)庫、中間件等都有一定深度的認知，否則當性能問題出現(xiàn)時，無從下手，不僅無法定位或排查性能問題，也不知道如何讓其它角色人員配合工作。
性能測試是一門很深的學(xué)問，需要不斷積累，擁有扎實的基礎(chǔ)知識，應(yīng)當多學(xué)多問多實踐。性能之路漫漫其修遠兮，謹以此篇文章共勉在性能路上走得更遠。
