1.7　性能測試

1.7.1　性能測試的目的

性能測試的目的是驗證軟件系統(tǒng)是否能夠?qū)崿F(xiàn)用戶提出的性能指標(biāo)，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，進(jìn)而優(yōu)化軟件。性能測試的目的有評估系統(tǒng)極限并發(fā)的能力、判斷系統(tǒng)是否有內(nèi)存溢出與高可用失效等相關(guān)現(xiàn)象，以及在長時間高壓下性能測試服務(wù)器因“疲勞”所產(chǎn)生的其他現(xiàn)象。

1.7.2　性能測試著重觀察的指標(biāo)

Web性能測試需著重觀察的聚合報告結(jié)果參數(shù)如表1-1所示。

1.7.3　性能測試存在的誤區(qū)

在性能測試開始之前，應(yīng)當(dāng)著重考慮服務(wù)器的硬件配置。各廠商通常表述自己的數(shù)據(jù)庫可以達(dá)到多少TPS，但很少說明自己服務(wù)器的硬件配置是怎樣的。實際上，計算機的硬件配置會極大地影響TPS結(jié)果，因此廠商推薦的數(shù)據(jù)庫和程序服務(wù)只能作為參考。在進(jìn)入生產(chǎn)環(huán)境之前，應(yīng)當(dāng)通過JMeter或基準(zhǔn)測試對數(shù)據(jù)庫進(jìn)行相應(yīng)的測試。

除硬件配置外，在性能測試準(zhǔn)備期間還應(yīng)著重注意當(dāng)前帶寬是否能夠滿足性能測試的需要，以免性能測試只返回帶寬上限的請求數(shù)目，而無法測試出應(yīng)用程序的極限。在帶寬不足的情況下，測試結(jié)果是無效的，需視為因帶寬不足而導(dǎo)致的結(jié)果不正確。

如果部分性能測試結(jié)果的錯誤率過高，則此次性能測試結(jié)果應(yīng)當(dāng)作廢，需視為因錯誤率過高而導(dǎo)致的結(jié)果不正確。因為一旦出現(xiàn)異常與錯誤，則接口響應(yīng)時間將是一個無法確定的值，即有些延時太高的線程無法返回，導(dǎo)致整體承載量下降。通常當(dāng)遇到錯誤率過高的程序時，應(yīng)當(dāng)先進(jìn)行優(yōu)化，再重新進(jìn)行性能測試。

性能測試的平均返回時間應(yīng)僅作為參考，在生產(chǎn)環(huán)境中，95百分位表示大多數(shù)正常用戶的響應(yīng)時間，99百分位可視為部分較卡用戶的響應(yīng)時間。不要以平均值作為普通用戶的響應(yīng)時間。

性能測試的最大返回時間通常被視作服務(wù)器的TimeOut時間，若該時間過長，則需要對程序進(jìn)行優(yōu)化，在限制TimeOut時間后再進(jìn)行測試，否則性能測試結(jié)果的參考性不高。線程在沒有被服務(wù)器返回的情況下，十分消耗服務(wù)器的CPU與內(nèi)存。與此同時，若中位數(shù)或90百分位的用戶響應(yīng)時間過長，則應(yīng)當(dāng)對應(yīng)用程序進(jìn)行優(yōu)化。例如，對于HTTP接口來說，5秒以上即算過長的響應(yīng)時間。若是高并發(fā)應(yīng)用程序，則響應(yīng)時間應(yīng)當(dāng)更少。

如果性能測試的最小時間為毫秒級，那么該數(shù)據(jù)通常是作為緩存存在的。如果性能測試的平均時間接近最小值，則該測試結(jié)果需要作廢，因為這很可能是服務(wù)器直接對數(shù)據(jù)進(jìn)行了返回，并沒有真正地進(jìn)入代碼與業(yè)務(wù)邏輯。此處需要根據(jù)系統(tǒng)的特性進(jìn)行斟酌。

在性能測試中，通常有壓力機與被測試機兩種類型的機器。由于性能測試工具與腳本同樣消耗性能，因此在實際工作中，可能出現(xiàn)多臺壓力機同時壓測一臺被測試機的情況，此時需要注意壓力機自身的CPU與內(nèi)存不要處于“爆表”的狀態(tài)，否則該測試結(jié)果應(yīng)當(dāng)作廢，需視為因壓力機無法正常運行而導(dǎo)致的結(jié)果不正確。

1.7.4　性能測試應(yīng)涵蓋的內(nèi)容

下面以登錄場景為例，通常性能測試應(yīng)至少包含以下測試報告：

? 在模擬生產(chǎn)環(huán)境的同時，95百分位的用戶的登錄響應(yīng)時間是否小于N秒，N為服務(wù)方提供的值。例如，單次登錄時間超過N秒則將視為系統(tǒng)高并發(fā)能力不足，需查看服務(wù)器配置及代碼，以免由于登錄時間過長而影響用戶體驗。諸如此類驗證響應(yīng)時間的接口，都需要按照百分位的方式進(jìn)行判斷，即絕大部分用戶的體驗是否正常。另外，對響應(yīng)時間需要有一個預(yù)期，即某系統(tǒng)達(dá)到什么樣的響應(yīng)時間則視為合格。因為系統(tǒng)的復(fù)雜度和使用場景不同，所以預(yù)期也不同。一般來說，單個用戶的登錄時間不應(yīng)超過2秒；打開App時，App初始化時間不應(yīng)超過3秒；頁面跳轉(zhuǎn)時間不應(yīng)超過1秒；跳轉(zhuǎn)下一頁的時間不應(yīng)超過0.5秒；在搜索相關(guān)數(shù)據(jù)時，結(jié)果返回時間不應(yīng)超過0.5秒。

? 在高并發(fā)場景下，用戶登錄是否請求了過多的接口。例如，在登錄之后，需要請求N個接口才能展示整體頁面，如果是在高并發(fā)情況下，則用戶體驗將會很差。如果在用戶登錄時或用戶登錄后需要請求過多的接口，則需要進(jìn)行優(yōu)化。例如，對于一個頁面可以分別讀取數(shù)據(jù)并部分展示，而不是在全部數(shù)據(jù)讀取完之后才打開頁面；在渲染頁面時是否有額外的資源消耗；在返回數(shù)據(jù)時是否有無用字段，是否可對接口進(jìn)行精簡、緩存等。

? 用戶登錄時是否包含監(jiān)控的功能，并且在高并發(fā)場景下監(jiān)控仍然能夠正常響應(yīng)，包括用戶行為監(jiān)控、性能監(jiān)控和服務(wù)端硬件監(jiān)控等。

? 在性能測試時需要進(jìn)行高并發(fā)下的慢連接、慢讀取、慢請求等安全測試，以保證在任何情況下都不會因客戶端的性能問題而影響服務(wù)器的性能。例如，某用戶使用App通過WebSocket協(xié)議連接Java服務(wù)器，在Java服務(wù)器主動推送數(shù)據(jù)后，由于App網(wǎng)絡(luò)較差無法正常收到數(shù)據(jù)，而使Java服務(wù)器內(nèi)存溢出導(dǎo)致崩潰。此時需要使用JMeter+Fiddler組合測試，即弱網(wǎng)下的高并發(fā)測試。

? 長時間大量用戶連續(xù)登錄和退出是否會引發(fā)內(nèi)存溢出、緩存失效或穿透緩存等問題。

? 連續(xù)使用虛假用戶進(jìn)行登錄，是否被有效攔截，是否會穿透緩存。