轉：Web網站性能測試分析及調優實例

　一、背景

　　前段時間， 性能測試團隊經歷了一個規模較大的門戶網站的性能優化 工做，該網站的開發和合做涉及多個組織和部門，並且網站的重要性不言而喻，同時上線時間很是緊迫，關注度也很高，因此對於整個團隊的壓力也很是大。

　　在此，把整個經歷過程給你們分享一下，包括了主要包括瞭如何使用性能測試的壓測工具，壓測前的性能問題評估，以及壓測執行後的性能問題分析、瓶頸定位。

　　該門戶網站的服務器是放在華通和阿里雲的平臺上的，因此對華通和阿里共建的雲平臺安全及應急措施方面要求很是高，須要團隊給予全力的保障和配合。

　　性能測試（Performance Testing）是集測試機管理、測試腳本管理、測試場景管理、測試任務管理、測試結果管理爲一體的性能雲測試平臺，能夠幫助您全方位的評估雲上系統性能。

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

　 　二、術語定義

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

　　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爲單位。

　　 三、評估

　　本次性能測試過程的參與人包括了阿里雲應急保障小組等多部門人員，網站爲外部供應商開發，阿里雲提供雲主機和 技術支持。

　　該網站以前前期也由其餘部門作了驗收工做，進行了完整的性能測試，報告顯示，性能較差，第一次測試，網站併發數沒有超過35個，第二次測試，網站上作了優化後，靜態頁面縮小後，併發用戶數100內 5s ，200內 90%響應在15s以上，隨着併發用戶數的增長，頁面響應最高可到20多秒，並且訪問明顯感受較慢，因此聯繫了阿里雲的技術支持，但願可以幫助診斷性能問題，給出優化建議。

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

　 　四、性能測試目標

　　· 併發用戶數：>=500

　　· 業務響應時間：<5秒

　　 五、分析

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

　　一個網站的響應通常由四部分時間組成，前端、網絡、服務器和 數據庫，前端主要是減少頁面大小，減少頁面請求數，優化頁面js等，網絡主要是使用CDN，優化鏈接數等，服務器主要是優化Apache，優化Tomcat，優化java代碼等，數據庫是優化sql語句，優化索引，優化數據存儲等。

　　 六、測試和優化

　　6.一、頁面前端分析及優化

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

　　· 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.二、服務端優化

　　通常核心頁面都要求在300毫秒如下，非核心頁面要求在500毫秒如下，同時重點關注併發時的負載和穩定，服務器端代碼和響應的快速穩定是整個頁面性能的重點。

　　 6.2.一、腳本編寫及場景構造

　　根據前期需求評估的內容，客戶是一個門戶網站，主要由不一樣功能頁面組成的，各個功能頁面當中又包含了靜態內容和異步動態請求，因此，性能測試的腳本的編寫主要涵蓋了各頁面的請求和相關靜態資源的請求，這裏存在一個串行和並行的概念：

　　串行：請求的頁面和頁面當中的靜態資源、異步動態請求組成一個同步請求，每個內容都做爲一個事務（也能夠共同組成一個事務，分開事務的好處是能夠統計各部分的響應時間），這樣壓測任務執行時，線程就會根據事物的順序分佈調用執行，至關於一個頁面的順序加載，弊端是沒法模擬實際IE的小範圍併發，但這樣測試的結果是最嚴格的。

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

　　場景併發用戶數：常常會遇到「設置多大併發用戶數合適？」的問題，由於在沒有任何思考時間的時候，咱們有一個簡單的公式：

　　VU（併發壓測用戶數） = TPS（每秒執行事務數） × RT（響應時間）

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

　　· a點：性能指望值

　　· b點：高於指望，系統安全

　　· c點：高於指望，拐點

　　· d點：超過負載，系統崩潰

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

　 　6.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.三、第二階段

　　找到幾個頁面的全部動態資源後，整合成爲一個事務，串行訪問，同時併發壓測，從而對純服務器端進行壓測，測試結果以下圖：

　　性能分析：頁面一和頁面二的響應時間分別達到了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.四、第三階段

　　經過性能測試模擬用戶實際訪問狀況，包括全部靜態資源，評估出當響應時間小於5秒的時候，最大支撐的併發用戶數。

　　測試結果：

　　能夠看到，全部的事務RT加起來小於5秒的狀況下，併發用戶數能夠達到3000(6個事務，6個腳本，每一個腳本500)，遠遠知足項目500個併發用戶的目標。

　　總結：

　　 6.2.五、第四階段

　　評估其餘非主站應用的性能以及含靜態頁面的其餘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.三、架構優化

　　單點登陸服務修改成SLB

　　檢索 修改成 SLB

　　內容管理雲平臺雲服務器實現行文件差別同步，同時冷備

　　新增4臺web機器

　 　七、總結

　　備註：服務器的CPU達到100% 這實際上是一個好的現象，說明咱們的邏輯所有已經走到了資源消耗上，而不是由外部其餘邏輯限制或blocked，這種現象帶來的好處就是，首先咱們能夠集中精力從減小代碼的資源消耗上解決問題，帶來性能的改善，其次，實在沒法優化咱們也能夠增長機器臺數，橫向擴展來讓性能成倍的提升，這也是用成本換性能的方法。固然，前提是架構上支持負載均衡的分佈式架構。

　　總的來講就是，這種狀況要不選擇從縱向優化，或者選擇從橫向擴展，均可以增長。

　 　八、遺留問題

　　時間緣由，測試頁面有限，有些頁面沒有測試覆蓋到，好比後臺頁面。

　　登陸系統存在內存風險，因爲用戶的緩存信息仍然存在單點問題，因此風險較大，同時系統壓力不知足要求，併發較高存在crash風險，將來得及發現瓶頸所在。完全解決必須使用OCS等緩存系統改造，同時優化數據庫。

　　Iframe框架形成用戶體驗很差，須要改掉，換成異步js接口方式。

　　後臺同步系統，對於資源消耗影響較大，須要持續優化。

　　平臺應該提供開發和測試進行自主壓測、分析、評估，同時提供統一的測試報告，保證各部分模塊的性能，整合起來才能保障整個門戶網站的性能。

　　CPU優化還須要繼續分析跟進，目前只是增長機器資源下降風險，成本較高。

　　上線發佈應該具有統一的迴歸驗證機制，而且平常須要持續優化，避免因爲後期代碼的改動致使性能降低。

 

 

 原文地址：http://www.51testing.com/html/59/n-3713159.html