門戶類網站效能測試分析及調優

阿新 • • 發佈：2019-02-07

轉自阿里雲：https://help.aliyun.com/document_detail/pts/test-case/PTS-TC08-ProtalWebSites.html?pos=1

1 背景

前段時間，效能測試團隊經歷了一個規模較大的入口網站的效能優化工作，該網站的開發和合作涉及多個組織和部門，而且網站的重要性不言而喻，同時上線時間非常緊迫，關注度也很高，所以對於整個團隊的壓力也非常大。
在此，把整個經歷過程給大家分享一下，包括了主要包括瞭如何使用效能測試的壓測工具，壓測前的效能問題評估，以及壓測執行後的效能問題分析、瓶頸定位。
該入口網站的伺服器是放在華通和阿里雲的平臺上的，所以對華通和阿里共建的雲平臺安全及應急措施方面要求非常高，需要團隊給予全力的保障和配合。
效能測試（Performance Testing）是集測試機管理、測試指令碼管理、測試場景管理、測試任務管理、測試結果管理為一體的效能雲測試平臺，可以幫助您全方位的評估雲上系統性能。

本次優化主要是使用了該測試平臺服務對客戶搭建在ECS上的伺服器進行多種型別（效能測試、負載測試、壓力測試、穩定性測試、混合場景測試、異常測試等）的效能壓測、除錯和分析，最終達到滿足期望預估的效能目標值，且上線後在高峰期滿足實際的效能和穩定要求。

2 術語定義

在介紹專案經歷之前，再明確一下測試當中用到的專業指標術語定義，包括但不僅限於以下：

PV: 即PageView, 即頁面瀏覽量或點選量，使用者每次重新整理即被計算一次。我們可以認為，使用者的一次重新整理，給伺服器造成了一次請求。

UV: 即UniqueVisitor,訪問您網站的一臺電腦客戶端為一個訪客。00:00-24:00內相同的客戶端只被計算一次。

TPS:TPS(Transaction Per Second)每秒鐘系統能夠處理的交易或事務的數量，它是衡量系統處理能力的重要指標。

響應時間: 響應時間是指從客戶端發一個請求開始計時，到客戶端接收到從伺服器端返回的響應結果結束所經歷的時間，響應時間由請求傳送時間、網路傳輸時間和伺服器處理時間三部分組成。

VU: Virtual user，模擬真實業務邏輯步驟的虛擬使用者，虛擬使用者模擬的操作步驟都被記錄在虛擬使用者腳本里。一般效能測試過程中，通俗稱之為併發使用者數。

TPS波動: 系統性能依賴於特定的硬體、軟體程式碼、應用服務、網路資源等，所以在效能場景執行期間，TPS可能會表現為穩定，或者波動，抑或遵循一定的上升或下降趨勢。我們用TPS波動係數來記錄這個指標值。

CPU: CPU資源是指效能測試場景執行的這個時間段內，應用服務系統的CPU資源佔用率。CPU資源是判斷系統處理能力以及應用執行是否穩定的重要引數。

Load: 系統正在幹活的多少的度量，佇列長度。系統平均負載，被定義為在特定時間間隔（1m，5m，15m）內執行佇列中的平均程序數
。

I/O: I/O可分為磁碟IO和網絡卡IO。

JVM: 即java虛擬機器，它擁有自己的處理器、堆疊、暫存器等，還有自己相應的指令系統。Java應用執行在JVM上面。

GC: GC是一種自動記憶體管理程式，它主要的職責是分配記憶體、保證被引用的物件始終在記憶體中、把不被應用的物件從記憶體中釋放。FGC會引起JVM掛起。

網速: 網路中的資料傳輸速率，一般以Byte/s為單位。通過ping延時來反映網速。

流量: 效能測試中，一般指單位時間內流經網絡卡的總流量。分為inbound和outbound，一般以KB為單位。

3 評估

本次效能測試過程的參與人包括了阿里雲應急保障小組等多部門人員，網站為外部供應商開發，阿里雲提供雲主機和技術支援。
該網站之前前期也由其他部門做了驗收工作，進行了完整的效能測試，報告顯示，效能較差，第一次測試，網站併發數沒有超過35個，第二次測試，網站上做了優化後，靜態頁面縮小後，併發使用者數100內 5s ，200內 90%響應在15s以上，隨著併發使用者數的增加，頁面響應最高可到20多秒，而且訪問明顯感覺較慢，所以聯絡了阿里雲的技術支援，希望能夠幫助診斷效能問題，給出優化建議。

測試業務	併發使用者數	平均響應時間(秒)	90%響應時間（秒）
首頁瀏覽	100	12.082	15.289
200	23.949	29.092
分頁瀏覽	100	8.973	12.343
200	18.846	24.106

經過會議討論後，評估出最終的測試目標：帶頁面的所有靜態資源一起，響應時間必須小於5秒，同時併發訪問使用者數最低500，TPS根據實際的結果來得出。

4 效能測試目標

併發使用者數：>=500
業務響應時間：<5秒

5 分析

通過效能測試前端分析工具(未開放)分析，頁面的響應時間88%左右都是消耗在前端資源載入上，伺服器端消耗只佔到了頁面響應的12%左右;

一個網站的響應一般由四部分時間組成，前端、網路、伺服器和資料庫，前端主要是減小頁面大小，減小頁面請求數，優化頁面js等，網路主要是使用CDN，優化連線數等，伺服器主要是優化Apache，優化Tomcat，優化java程式碼等，資料庫是優化sql語句，優化索引，優化資料儲存等。<rb>

6 測試和優化

6.1 頁面前端分析及優化

我們對頁面的優化仍然從前端開始，首先通過效能測試的前端測試工具（未開放）進行掃描，我們發現以下問題並優化：

Js較大，無壓縮，同時存在重複請求，最多一個js載入4次，已做壓縮和減少。
Js位置不合理，阻礙頁面載入。
外部css 考慮本地實現，減少呼叫
Banner 背景圖片較多，無壓縮，建議合併
頁面1的後臺.do有4個，減少為3個
頁面2的後臺do有 2個，減少為1個
存在載入失敗連結，404失敗，同時次數非常多，更換為cnzz
頁面載入外部資源失敗 (qq等)，且不穩定
分享功能比較慢
外部資源建議非同步實現，目前全部是jquery渲染，iframe巢狀，時間資源限制，後期優化
儘量減少或者不使用iframe
頁面請求數太多，主要是js和css重複載入問題和圖片較小導致的。經過以上修改及配置伺服器靜態資源快取後，效能提高25%，首頁響應從1.5秒提高到1.1秒，並且前端優化持續進行。

6.2 服務端優化

一般核心頁面都要求在300毫秒以下，非核心頁面要求在500毫秒以下，同時重點關注併發時的負載和穩定，伺服器端程式碼和響應的快速穩定是整個頁面效能的重點。

6.2.1 指令碼編寫及場景構造

根據前期需求評估的內容，客戶是一個入口網站，主要由不同功能頁面組成的，各個功能頁面當中又包含了靜態內容和非同步動態請求，所以，效能測試的指令碼的編寫主要涵蓋了各頁面的請求和相關靜態資源的請求，這裡存在一個序列和並行的概念：

序列：請求的頁面和頁面當中的靜態資源、非同步動態請求組成一個同步請求，每一個內容都作為一個事務（也可以共同組成一個事務，分開事務的好處是可以統計各部分的響應時間），這樣壓測任務執行時，執行緒就會根據事物的順序分佈呼叫執行，相當於一個頁面的順序載入，弊端是無法模擬實際IE的小範圍併發，但這樣測試的結果是最嚴格的。

並行：各個頁面之前可以使用不同的任務，採用並行的混合場景執行，同時設定一定的比例（併發使用者數），保證伺服器承受的壓力與實際使用者訪問相似。

場景併發使用者數：經常會遇到“設定多大併發使用者數合適？”的問題，因為在沒有任何思考時間的時候，我們有一個簡單的公式：
VU（併發壓測使用者數） = TPS（每秒執行事務數） × RT（響應時間）

所以，在尋找合適的併發使用者數上，建議使用效能測試的“梯度模式”，逐漸增加併發使用者數，這個時候壓力也會越來越大，當TPS的增長率小於響應時間的增長率時，這就是效能的拐點，也就是最合理的併發使用者數；當TPS不再增長或者下降時，這個時候的壓力就是最大的壓力，所使用的併發使用者數就是最大的併發使用者數。如果此時的TPS不滿足你的要求，那麼就需要尋找瓶頸來優化。如下圖演示的一個性能曲線：

a點：效能期望值
b點：高於期望，系統安全
c點：高於期望，拐點
d點：超過負載，系統崩潰

注意：使用外網地址壓測可能會造成瞬時流量較大，造成流量計費，從而產生費用，建議可以使用內網地址壓測，避免損失。

6.2.2 第一階段

在按照客戶提供的4個URL請求構造場景壓測以後，同時根據實際情況和客戶要求，使用效能測試，構造相應的場景和指令碼後，模擬使用者實際訪問情況，並且指令碼中加上了img、js、css等各一個的最大靜態資源：

條件：5臺ECS機器，200併發使用者數，一個後臺頁面加3個靜態頁面（共150K）
結果：靜態4000TPS，動態1500TPS，伺服器資源：CPU 98%

分析和優化：

伺服器資源消耗較高，超過75%，存在瓶頸，分析平臺顯示：

分析發現原來是apache到tomcat的連線等待導致，現象是100個併發壓測，就有100個tomcat的java執行緒，而且全部是runnable的狀態，輪詢很耗時間。
同時發現使用者使用的是http協議，非ajp協議，不過這個改動較大，需要使用mod_jk模組，時間原因，暫緩。
解決方法：修改了Apache和tomcat的連線協議為nio協議，同時去除ssl 協議。Tomcat連線資料庫池由30初始調整為300，減少開銷
```
&lt;Connectorport="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
            connectionTimeout="20000"
            redirectPort="8443" /&gt;
```

效能對比：

再進行1輪壓測含動態含靜態檔案，TPS能夠從1w達到2.7W，效能提高將近3倍，並且tomcat的執行緒從原來的200跑滿，降到100附近並且執行緒沒有持續跑滿，2.6W TPS時候CPU在80%附近
發現機器的核數都是2核，8G記憶體，對於CPU達到98%的情況，CPU是瓶頸，而對於應用來說比較浪費，所以將2核統一升級為4核。
擴充套件機器資源，從目前的4臺擴到6臺，同時準備4臺備份，以應對訪問量較大的情況。

思考和風險：

非同步請求處理:客戶所提供的url都是html靜態，雖然頁面當中含動態資料，但分析後發現動態資料都是通過jquery執行然後iframe巢狀的，所以不會隨著html檔案的載入而自動載入，需要分析所有的動態頁面，同時壓測，這是頁面存在非同步請求需要關注的地方。
Iframe:Iframe巢狀頁面的方式優點是靜態資源呼叫方便、頁面和程式可以分離，但是它的缺點也顯而易見，包括樣式、指令碼額外注入，增加請求等等；還有搜尋引擎搜素不到內容；iframe建立比其他元素慢1~2個數量級；資源重複載入；iframe會阻塞頁面載入，阻塞onload事件；佔用主頁連線池；html5不再支援。所以建議儘量不要使用或者少使用。
[font='Times New Roman']: 指令碼錄製和模擬實際使用者訪問。當用戶的圖片、javascript、CSS等靜態資源和後端程式碼在同一臺伺服器上時，需要模擬使用者的實際訪問請求，壓測指令碼涵蓋所有連結和資源。那麼使用指令碼錄製功能就可以採集更全更完整的指令碼。

6.2.3 第二階段

找到幾個頁面的所有動態資源後，整合成為一個事務，序列訪問，同時併發壓測，從而對純伺服器端進行壓測，測試結果如下圖：

效能分析：頁面一和頁面二的響應時間分別達到了5秒和2秒，效能較差，整體TPS只有11

效能分析：
分析發現響應時間高的原因主要在RDS資料庫上，資料庫此時的CPU已經達到100%，處理較慢，懷疑跟sql有關，分析慢sql。
優化方法：
資料庫第一批優化完畢，優化了6條sql語句之前5s左右，優化後在150ms左右，資料庫的QPS 從1k上升到6k。
RDS優化內容包括：
優化點主要是調整慢sql的索引，部分sql需要調整表結構和sql寫法，需要應用配合才能完成優化，優化前QPS在1000左右，優化後QPS到達6000

前端響應時間從5秒降低到150毫秒，前臺TPS由150提升到1500.總的TPS可以達到2000。

6.2.4 第三階段

通過效能測試模擬使用者實際訪問情況，包括所有靜態資源，評估出當響應時間小於5秒的時候，最大支撐的併發使用者數。

測試結果：

可以看到，所有的事務RT加起來小於5秒的情況下，併發使用者數可以達到3000(6個事務，6個指令碼，每個指令碼500)，遠遠滿足專案500個併發使用者的目標。

總結：

6.2.5 第四階段

評估其他非主站應用的效能以及含靜態頁面的其他5個頁面內容，包括：

搜尋壓測
操作壓測
登入壓測
證書登入
針對5個常用場景進行混合壓測

測試結果:

發現的風險和問題：

測試發現，流量存在非常明顯的波動，不經過某模組就無此問題，發現有大量的reset連線，會診後總結：埠複用導致的問題。FULL NAT模式和LVS存在相容性問題。最終結果: 由於存在相容性問題，影響到網站的穩定性和效能，暫時載入該模組，待問題解決後再加。先使用另外一個模組代替
.凌晨2點，針對單點使用者登入進行了壓測，發現100併發，該業務介面已宕機，分析結果:Cache快取設定太小，1G記憶體容量導致記憶體溢位，已建議修改為4G。使用http協議效能不佳，早上4點30進行少量程式碼優化後，業務直接不可用，環境出現宕機無法修復，我們快速進行快照恢復，5分鐘內恢復3臺業務機，雲產品的優勢盡顯。使用者log日誌撐滿系統盤，並且一直不知這臺雲主機還有資料盤，產品上我們要做反思。幫助使用者已進行掛盤及日誌遷移至資料盤，減少單盤的IO壓力。
Web伺服器資料同步，發現伺服器io和cpu壓力過大。加入inotify機制，由檔案增量同步，變更為檔案系統的變化通知機制。將冷備及4臺備用web機器使用該方式同步，目前，檢視內容分發主機IO和CPU使用率已回覆正常範圍同步推送時間，根據伺服器的負載，進行調整同步時間。今天已修改為2分鐘。由於備份量大，晚上進行全量同步。新增4臺備用機，已關閉apache 埠自動從slb去除，作為冷備
由於目前單點使用者登入入口存在架構單點宕機風險，進行登入和未登入風險驗證，確認，如使用者已登入後，登入業務系統出現宕機，進行簡單的頁面點選切換，不受影響
記憶體優化

按照JVM記憶體管理模式，調整系統啟動引數，如果一臺ECS部署一臺伺服器，建議不要選擇預設的JVM配置，應該設定記憶體為實體記憶體的一半，同時設定相應的YTC和FGC策略，觀察Old區變化，避免大量Full GC，建議Full GC頻率大於1小時，同時GC時間小於1秒鐘。

6.3 架構優化

單點登入服務修改為SLB
檢索修改為 SLB
內容管理雲平臺雲伺服器實現行檔案差異同步，同時冷備
新增4臺web機器

7 總結

備註：伺服器的CPU達到100% 這其實是一個好的現象，說明我們的邏輯全部已經走到了資源消耗上，而不是由外部其他邏輯限制或blocked，這種現象帶來的好處就是，首先我們可以集中精力從減少程式碼的資源消耗上解決問題，帶來效能的改善，其次，實在無法優化我們也可以增加機器臺數，橫向擴充套件來讓效能成倍的提高，這也是用成本換效能的方法。當然，前提是架構上支援負載均衡的分散式架構。
總的來說就是，這種情況要不選擇從縱向優化，或者選擇從橫向擴充套件，都可以增加。

8 遺留問題

時間原因，測試頁面有限，有些頁面沒有測試覆蓋到，比如後臺頁面。
登入系統存在記憶體風險，由於使用者的快取資訊仍然存在單點問題，所以風險較大，同時系統壓力不滿足要求，併發較高存在crash風險，未來得及發現瓶頸所在。徹底解決必須使用OCS等快取系統改造，同時優化資料庫。
Iframe框架造成使用者體驗不好，需要改掉，換成非同步js介面方式。
後臺同步系統，對於資源消耗影響較大，需要持續優化。
平臺應該提供開發和測試進行自主壓測、分析、評估，同時提供統一的測試報告，保證各部分模組的效能，整合起來才能保障整個入口網站的效能。
CPU優化還需要繼續分析跟進，目前只是增加機器資源降低風險，成本較高。
上線釋出應該具備統一的迴歸驗證機制，並且日常需要持續優化，避免由於後期程式碼的改動導致效能下降。