導讀 id:top100case
淘寶網的性能測試自動化平台具備了分布式、高并發、低成本、可擴充等特性的性能測試平台工具，它包括性能項目管理、環境管理、腳本管理、場景管理、任務管理、監控管理、結果管理等子產品，以及前端性能測試子產品、性能測試報告子產品、性能缺陷子產品、和性能基線子產品等，背景還有完善的分布式壓測引擎管理平台。
本文結合性能測試在企業雲架構上的應用案例，介紹淘寶網的性能測試從無到有經曆的階段，同時介紹自主研發的自動化性能測試平台誕生的條件和過程，解析如何使用性能測試的方法保障企業應用的性能，同時如何建構一個性能自動化測試平台。
（全文共9698字 預計閱讀時長：12分鐘）
淘寶網性能測試團隊成立于2009年1月，當時團隊隻有2個人。從那個時候起，團隊成員便開始參與或負責淘寶網的核心技術架構變革的性能測試工作，當時的“五彩石”項目就是團隊的一個關鍵裡程碑，它代表了性能測試團隊的第一次大規模實踐和産出。
團隊剛好經曆淘寶網的技術由java初期時代到大規模分布式系統時代，也經曆了在這個時代所産生的問題。
性能測試團隊發展至今，其成長過程大緻可分為業務發展、平台發展和産品上雲三個階段。
淘寶網性能測試的演變
淘寶網性能測試的發展過程如表1所示。
表1 淘寶網性能測試的發展
● 1.1 業務發展階段（2016年1月到2011年8月）
它是性能測試團隊成長的基礎，是性能團隊、積累和總結的過程。這個階段在大量的做項目和日常的業務測試，每個成員都同時承擔着超過5條産品線的項目性能工作，同時測試的項目最多時可達十餘個。在這種高強度高壓力的業務測試曆練中，團隊的每一位成員都擁有了豐富的業務測試經驗，對今後團隊的發展、技術發展和平台發展都起到了重要的基石作用。
在這個團隊雛形時期，産出了具備一定參考價值的《性能測試白皮書》、《性能測試寶典》、《性能測試大型項目壓測模型》、《性能測試常用工具和使用方法》、《性能測試流程》等文檔；同時也産出了性能測試的各種方案，包括《性能測試設計方案模闆》、《性能環境守則》、《性能環境目錄規範》、《性能測試報告模闆》、《性能測試過程檔案》、《性能測試環境搭建規程》、《性能測試流程圖》、《性能測試日報模闆》、《性能測試資源申請模闆》等，這些文檔和方案直到現在對于業界新人仍然起到了入門、學習和引導的作用。
● 1.2 平台發展階段（2011年9月到2013年8月）
它是性能測試團隊創新的階段和過程。業務發展到一定階段，必然需要産品、平台的支援才可以走得更遠，更加專業，2011年的8月，團隊的tl意識到以下幾點：
我們的工具仍然是花費昂貴的loadrunner；
人手幾台loadrunner實體機，所做的項目仍然有限；
大項目的支援，高并發的支援，仍然做的不好；
工具和人力都成為制約項目性能測試發展的瓶頸；
淘寶普遍使用hsf接口的壓測需要封裝成http請求，工具使用存在一定的局限性；
更多人想參與到性能測試工作中來。
在當時的系統工具和平台部門下，我們這樣一個專業的性能測試團隊，卻沒有一個适合自己、适合淘寶的性能測試工具和平台，這種情況的改變迫在眉睫，去除loadrunner更是當務之急。
在這個階段，我們為了解決性能資源申請和透明化、流程化的瓶頸，産出了“t-work性能中心”；為了解決線上線下性能對比的問題，和核心團隊合作，開發了“線上線下跟蹤體系平台”、“線上線下容量評估平台”，也就是csp的前身；緊接着團隊自己開發了“性能自動化測試平台-pap”當時還是以tsung為主性能測試壓測引擎，在平台積累了一定量的使用者以後，我們繼續開發了核心壓測引擎“分布式壓測引擎-trunner”、“壓測引擎管理平台-trunner-console”、“前端性能測試平台”等。
同時我們除了前端性能測試，也開始着手研究用戶端性能測試方法（旺旺）、無線性能測試方法等，使得性能測試在支援阿裡集團各bu上更加專業、更加廣泛，且朝着體系化、平台化和系統化的方向發展。
● 1.3 共建和雲測試發展階段（2013年9月至今）
在這個階段，我們團隊邀請了更多的人員參與共建。為了适應發展，團隊拆分為了平台和業務兩個分支。平台的同學繼續維護目前的pap，同時提高使用者體驗；而業務的同學則分拆到各個業務線。其目的一方面是幫助各業務線建立一套适合自己産品線的性能測試的基線、标準和方法，同時建立回歸體系，保障線上産品的穩定；另一方面幫助各業務線測試同學的成長，讓性能測試的範圍覆寫面更廣，使得面向人人性能測試的終極目标更進一步。
這其間，我們團隊獲得了技術品質部共建優秀團隊獎，同時産品共建支援了包括qr、tmd、dubbo、qtest、ddos等更多協定和工具的性能測試工作；也支援了作為jae的對外核心性能測試平台的工作，同時我們通過雙十一和聚石塔的合作，逐漸開始向外部客戶發展。從剛開始的isv到目前的阿裡雲所有客戶，以及面向更多的客戶，基于pap開發了支援isv雙十一等活動的jst_pts和支援阿裡雲客戶的aliyun_pts，同時也圍繞着阿裡雲客戶的需求，融入dts和管理平台，引入計費模式，最終使得pts對外正式釋出收費，向雲測之路又邁出了堅實的一步。
性能測試評估和流程
在支援外部客戶性能測試的過程中，我們發現，大量的使用者認為性能測試隻是傳統的壓測，使用壓測工具，配置一個url或者錄制一個url就完成了，然後直接開始壓測。
其實工具隻是一個輔助手段，一個工具有大量的配置規則，一個url也有很多的内容組成，要找到一個适合自己的壓測工具、壓測方法和壓測手段，同時也要了解壓哪個url，以及壓測url的哪一部分是适合的。
例如一個頁面有以下的問題：
第一次測試，網站并發數沒有超過35個，大量逾時。
第二次測試，網站上做了優化以後，并發使用者數100以内時響應 5s ，200以内時90%響應在15s以上，随着并發使用者數的增加，頁面響應最高可到20多秒。
注：測試工具loadrunner
我們該如何評估和分析呢？
首先我們要了解這個url的通路過程如圖1所示，分别從通路路徑和url包含内容來分析。
圖1 url的通路過程
這裡，url經過浏覽器，通過網絡進入伺服器；再通過網絡，進入資料庫存儲，最後傳回給使用者。
是以性能的評估也要從這幾個方面去分析，我們壓測的是不是這幾個路徑，需要壓測什麼，需要怎麼壓。
根據以上的路徑分析出：
使用者的響應時間是指整個頁面加載時間；
壓測的用戶端是否成為瓶頸；
使用者測試的網絡帶寬是否成為瓶頸；
使用者的伺服器、資料庫毫無壓力；
使用者的測試方法存在問題。
● 2.1 前端性能測試
檢視圖2我們發現，一個頁面的通路，90%以上的時間都消耗在了前端資源（js、css、img）的加載和渲染上，隻有5%～10%是消耗在伺服器端的響應上。而例子中使用者使用loadrunner錄制的腳本來做的壓力測試（壓測），就是帶着所有的靜态資源來壓測，而一個頁面有時候會很大，假如是1兆，那麼普通網卡最多就是千兆網卡，有些pc機甚至隻是百兆網卡（bit），換算下來一秒鐘最多通路100m/秒（千兆網卡），是以對于一個1m（byte）大小的頁面，tps最多就是100，已經達到網卡的極限，再多的并發也沒有用，是以就會遇到響應時間上升的情況。
圖2 頁面通路的時間消耗分布
反觀淘寶的靜态資源都是存放在cdn上，而且有獨立域名，這樣使用者不會和伺服器響應共用一個網絡，就不存在網卡的瓶頸。
淘寶網的性能測試主要針對5%-10%的html伺服器資源進行壓測的，基于以下兩個因素：
靜态資源都沒有問題，是以無需壓測，也無法壓測，不同使用者的通路cdn站點不同。
采用區域網路方式，盡量忽略網絡的影響。因為使用者的網絡是無法真實模拟的，那麼隻要提高伺服器并發就可以了，不需要關注由于網絡導緻的波動等情況，保持伺服器性能和穩定，那麼目标就完成了。
是以，淘寶網的性能測試一般頁面響應時間是在300毫秒以下，接口的響應時間在70毫秒或100毫秒以下，就是這個原因。
雖然伺服器端的響應隻占整個頁面響應的5%～10%，但是這個響應是所有使用者體驗的首要響應，隻有伺服器端盡快的響應，才能夠讓後面基于html上的其他資源盡快響應。是以保障伺服器端的響應是這個性能測試過程中最重要的環節，同時在保障伺服器端響應時間的基礎上，更要保障伺服器的穩定，也就是測試高并發的情況。
那麼是否前端就不需要關注了呢？答案是否定的。前端的測試方法由于是浏覽器用戶端通路的方式，所有的靜态資源在網絡環境滿足的條件下，需要用戶端使用者自己的電腦去渲染，包括js執行等，是以前端的測試有其自身特殊的方法，常見的前端測試工具包括以下産品，如圖3所示。
圖3 常見的前端測試工具
而pap也有基于webpagetest的前端性能測試工具，具體的使用方法這裡就不再介紹。經過測試後，可以優化的點包括：
靜态資源無緩存；
js較大，無壓縮，存在重複請求；
js位置不合理；
外部css依賴較多；
banner圖檔較大，且多，無壓縮；
背景接口請求較多，可以合并；
頁面存在請求失敗和跳轉的外部資源；
外部依賴接口較慢；
頁面請求數較多，主要是js和css重複加載。
…
優化效果對比如圖4所示。
圖4 優化效果對比
loadrunner裡面，去除靜态資源的選項如表2所示。
表2 loadrunner裡去除靜态資源的選項
● 2.2 伺服器端性能測試
了解了前端性能測試的原因和方法，我們來看伺服器端性能測試方法。
首先，需要了解一下性能測試的名額，如表3所示。
表3 性能測試名額
圖5 load
圖6 性能測試的名額gc
● 2.3 pv與tps的分析
對于一個性能測試，最關鍵的tps是怎麼換算的。例如使用者的預估或者實際的網站通路（pv/天）符合一個正态分布，如圖7所示，從0點到24點，那麼使用者高峰通路的每秒pv，就是我們所要計算的tps，也就是我們壓測的性能目标。如圖8所示。
圖7 pv曲線
按照80/20原則，我們需要找到整個面積的80%消耗在多長時間内，比如我們将通路的圖拆分成不同的矩形，計算出每個矩形的面積，然後倒序排列相加，找到80%面積的點的時間如圖8所示，大概是7/16。
圖8 pv通路圖拆分成不同的矩形換算tps
是以，平均一天的pv就是pv×80%/（7/16）=x，這個x是平均值，由此計算出它和高峰的系數，pv（f）/x=y，y就是系數。那麼，使用者隻要知道他的一天pv是多少，根據這個公式就可以計算出高峰pv，也就是所說的tps，然後把它作為性能測試的目标來壓測。
● 2.4 測試方法诠釋
圖9 系統處理能力的變化趨勢
圖9顯示了性能測試過程中，随着壓力的增加，系統處理能力的變化趨勢：
a點：性能期望值
b點：高于期望，系統安全
c點：高于期望，拐點
d點：超過負載，系統崩潰
我們可以做的性能測試a點（性能測試）、b點（負載測試）、c點（壓力測試）、d點（異常測試），以及基于這幾種類型的長時間穩定性測試，如表4所示。
表4 4種類型的穩定性測試
一般測試，很難将伺服器給壓至崩潰，壓測到負載測試後，tps便相對穩定下來，響應時間反而增長，是以當壓力到tps的增長率小于響應時間（rt）的增長率時，這個時候的并發，就是系統所能承受的最大并發，再大便無意義，也不便于發現和分析問題。壓力測試通過标準如表5所示。
表5 通過标準
基于雲産品的門戶網站性能優化案例
● 3.1 背景
不久前，有幸經曆了一個規模較大的門戶網站的性能優化工作，該網站的開發和合作涉及多個組織和部門，同時上線時間非常緊迫，關注度也很高。
下面将以此項工作作為典型案例，與大家分享一下基于雲産品的門戶網站性能優化，内容包括如何使用pts的壓測工具、壓測前的性能問題評估，以及壓測執行後的問題分析、瓶頸定位等。
該門戶網站的伺服器存放在華通和阿裡雲的平台上，是以對華通和阿裡共建的雲平台安全及應急措施要求也非常高，需要團隊給予全力的保障和配合。
先介紹一下pts，性能測試服務（performance test service，簡稱pts）是集測試機管理、測試腳本管理、測試場景管理、測試任務管理、測試結果管理為一體的性能雲測試平台，可以幫助您全方位的評估雲上系統性能。如表6所示。
表6 pts的産品優勢
本次優化主要是使用了該測試平台服務對客戶搭建在ecs上的伺服器進行多種類型（性能測試、負載測試、壓力測試、穩定性測試、混合場景測試、異常測試等）的性能壓測、調試和分析，最終達到滿足期望預估的性能目标值，且上線後在高峰期也滿足了實際的性能和穩定要求。
● 3.2 評估
本次性能測試過程的參與者包括了阿裡雲應急保障小組等多部門人員，網站為外部供應商開發，阿裡雲提供雲主機和技術支援。
該網站前期已由其他部門做了驗收工作，并進行了完整的性能測試。報告顯示，性能較差。第一次測試，網站并發數沒有超過35個；第二次測試，網站做了優化後，靜态頁面縮小，并發使用者數100内5秒，200内90%響應在15秒以上。随着并發使用者數的增加，頁面響應最高可到20多秒，而且通路明顯感覺較慢，聯系了阿裡雲的技術支援，希望能夠幫助診斷性能問題，給出優化建議。真正的測試優化時間隻有不到3天時間。如表7所示。
表7 優化後的測試時間
經評估得出最終的測試目标要求：帶頁面的所有靜态資源，響應時間必須小于5秒，同時并發通路使用者數最低500，tps根據實際的結果得出。
● 3.3 分析
結合loadrunner的使用經驗，團隊的第一感覺就是使用者測試方法可能有誤，一個頁面加載對于阿裡的應用來說，都是1秒以下的，也就是毫秒級别的，不會出現幾秒的現象。而使用者測試結果都以秒來衡量，是以測試頁面肯定是帶了靜态資源一起壓測的。
這樣的測試，其實模拟了使用者的整個頁面通路情況。它有一個弊端，就是帶寬。一般人的電腦都是百兆網卡，最好的伺服器目前也隻是千兆網卡，萬兆很少見，如果一個頁面按照500k的大小來計算，百兆網卡的壓測用戶端，最大1秒鐘并發約25個（100m*1000(kb)/8/500(kb)=25），網卡打滿後，再增加壓力，增加并發，tps不會升高，而響應時間則會升高，才會達到1秒，5秒，甚至20秒，有時候還會逾時。
但這種方法客戶認為最接近使用者體驗，屬于頁面全部加載完了。我們分析，一方面浏覽器加載靜态資源肯定不是串行的，同時還有js的執行時間無法模拟；另一方面靜态資源都是會緩存的，如果每次壓測都要下載下傳靜态資源也不妥。是以這種方式并沒有真實模拟使用者通路的，如圖10所示。當然也不排除有些測試工具是可以模拟這種并發的，至少在該項目中，沒有這樣去做。
圖10 頁面加載時間分布圖
注：頁面的響應時間88%左右都消耗在前端資源加載上，伺服器端消耗隻占到了頁面響應的12%左右。
這種場景适合如js、css、image等靜态資源和後端代碼放置在同一台伺服器上的情況。
一個網站的響應一般由前端、網絡、伺服器和資料庫四部分時間組成，如圖11所示。前端主要是減小頁面大小，減小頁面請求數，優化頁面js；網絡主要是使用cdn，優化連接配接數；伺服器主要是優化apache、tomcat、java代碼等，資料庫則優化sql語句，優化索引，優化資料存儲等。
圖11 組成網站響應的4部分
● 3.4 測試和優化
先不讨論原來的測試方法是否準确，我們首先以測試和優化為目的，對該門戶網站進行測試和分析，内容包括以下方面。
3.4.1 頁面前端分析和優化
對頁面的優化從前端開始。首先通過pts的前端測試工具（未開放），再結合yslow（yahoo前端測試工具）、pagespeed等掃描，發現以下問題并進行優化。
靜态檔案無緩存，伺服器配置解決；
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秒，并且前端優化持續進行。如表8。
表8 前端優化的結果
前端頁面最終結果：
最初的startrender(頁面首次渲染)時間由1.5秒變為0.8秒；完全加載時間由4秒下降至2.8秒；domready（dom結構完成）時間由3.2秒下降至2.75秒。
遺留問題：其他頁面未做測試，前端測試工具會在今後的發展中整合在阿裡雲pts的性能測試平台當中，整體關注頁面性能。
3.4.2 伺服器端優化
伺服器端優化主要就是針對圖3中12%的頁面性能，一般核心頁面要求在300毫秒以下，非核心頁面要求在500毫秒以下，同時重點關注并發時的負載和穩定，伺服器端代碼和響應的快速穩定是整個頁面性能的重點。
pts腳本編寫和場景構造
根據前期需求評估的内容，客戶是一個門戶網站，是由不同功能的頁面組成，各個功能頁面中又包含了靜态内容和異步動态請求，是以，pts腳本的編寫主要涵蓋了各頁面的請求和相關靜态資源的請求，這裡存在一個串行和并行的概念。
串行：請求的頁面和頁面當中的靜态資源、異步動态請求組成一個同步請求，每個内容都作為一個事務（也可以共同組成一個事務，分開事務的好處是可以統計各部分的響應時間），這樣壓測任務執行時，線程就會根據事務的順序分布調用執行，相當于頁面的順序加載，弊端是無法模拟實際ie的小範圍并發，但這樣測試的結果是最嚴格的。
并行：各個頁面使用不同的任務，采用并行的混合場景執行，同時設定一定的比例（并發使用者數），保證伺服器承受的壓力與實際使用者通路相似。
場景并發使用者數：經常會遇到“設定多大并發使用者數合适？”的問題，我們有一個公式。
在尋找合适的并發使用者數上，建議使用pts的“梯度模式”，逐漸增加并發使用者數，這個時候壓力也會越來越大，當tps的增長率小于響應時間的增長率時，這就是性能的拐點，也就是最合理的并發使用者數；當tps不再增長或者下降時，這個時候的壓力就是最大的壓力，所使用的并發使用者數就是最大的并發使用者數。如果此時的tps不滿足你的要求，那麼就需要尋找瓶頸來優化。如圖9示範的一個性能曲線：
注意：使用外網位址壓測可能會造成瞬時流量較大，産生流量計費，建議使用内網位址壓測，避免損失。
第一階段
在按照客戶提供的4個url請求構造場景壓測以後，根據實際情況和客戶要求，使用pts，構造相應的場景和腳本，模拟使用者實際通路情況，并且腳本中加上了img、js、css等各一個的最大靜态資源。
條件：5台ecs機器，300并發使用者數，一個背景頁面加3個靜态頁面（共150k）；
結果：靜态4000tps，動态1500tps，伺服器資源：cpu 98%。如表9所示。
表9 使用pts腳本編寫和場景構造的條件和結果
分析和優化
伺服器資源消耗較高，超過75%，存在瓶頸，分析平台顯示如圖12所示。
圖12 分析平台顯示結果
分析：主要原因是apache到tomcat的連接配接等待導緻，現象是100個并發壓測，就有100個tomcat的java線程，而且全部是runnable的狀态，輪詢耗時較多。
同時發現使用者使用的是http協定，非ajp協定。但這個改動較大，需要使用mod_jk子產品，時間原因，暫緩。
解決方法：修改了apache和tomcat的連接配接協定，以nio協定取代ssl協定。tomcat連接配接資料庫池由30初始調整為300，減少開銷
<connector port=＂8080＂ protocol=＂org.apache.coyote.http11. http11nioprotocol＂connectiontimeout=＂20000＂ redirectport=＂8443＂ />
性能對比：
再進行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不再支援。是以建議盡量不要使用或者少使用。
腳本錄制和模拟實際使用者通路
當使用者的圖檔、javascript、css等靜态資源和後端代碼在同一台伺服器上時，需要模拟使用者的實際通路請求，壓測腳本涵蓋所有連結和資源。那麼使用腳本錄制功能就可以采集更全更完整的腳本。
第二階段
找到幾個頁面的所有動态資源後，整合成為一個事務，串行通路，同時并發壓測，進而對純伺服器端進行壓測。由于動态頁面依賴rds資料庫，是以性能相對較差，測試結果如表10所示。
表10 測試結果
對以上通過測試結果的頁面一和頁面二的響應時間分别達到了5秒和2秒（圖13），性能較差，整體tps隻有11，如圖14所示。
圖13 第二階段的響應時間
圖14 第二階段的tps
對以上結果的性能分析：響應時間長的主要原因在rds資料庫，資料庫此時的cpu已經達到100%，處理較慢，分析應與sql有關。
優化方法：資料庫第一批優化完畢，優化了6條sql語句，使原來5s左右時間，優化至150ms左右，資料庫的qps 從1k上升到6k。
rds優化内容包括：優化點主要是調整慢sql的索引，部分sql需要調整表結構和sql寫法，需要應用配合才能完成優化。優化前qps在1000左右，優化後qps到達6000，如圖15所示。
圖15 優化後的qps到達6000
前端響應時間從5秒降低到150毫秒，前台tps由150提升到1500，優化前後對比如圖16和圖17所示。
圖16 優化前的響應時間
圖17 優化後的響應時間
優化後的性能資料如表11所示。
表11 優化後的性能資料
總的tps可以達到2000，有個失敗的頁面存在問題，忽略。
第三階段
壓測目的：通過pts模拟使用者實際通路情況，包括所有靜态資源，評估當響應時間小于5秒的時候，最大支撐的并發使用者數。
測試結果如表12所示。
表12 當響應時間小于5秒時，最大支撐的并發使用者數統計時間段
可以看到，所有的事務rt加起來小于5秒的情況下，并發使用者數可以達到3000，滿足測試要求。如圖18和圖19所示。
圖18 第三階段的tps
圖19 第三階段的響應時間
優化前後的對比如表13所示。
表13 優化前後的三項對比
第四階段
壓測目的：評估其他非主站應用的性能以及含靜态頁面的其他5個頁面，内容包括：搜尋壓測、操作壓測、登入壓測、證書登入和針對5個常用場景進行混合壓測。
測試結果如表14所示。
表14 其他非主流站應用的性能及靜态頁面5個頁面的測試成果
備注：
5台ecs伺服器構成的叢集；
雖然個别頁面已經過優化，但仍然存在可以調整的空間。
風險和問題：
① 測試發現流量存在非常明顯的波動，不經過某子產品就無此問題，發現有大量的reset連接配接，會診後得出端口複用導緻的問題以及full nat模式和lvs存在相容性問題。
由于存在相容性問題，影響到網站的穩定性和性能，暫時不加載該子產品，待問題解決後再加。先使用另外一個子產品代替。
不通過子產品的測試結果，如圖20所示。
圖20 不通過子產品的測試結果
通過子產品後測試結果，如圖21所示。
圖21 通過子產品後的測試結果
② 淩晨2點，針對單點使用者登入進行了壓測，發現100并發，該業務接口已當機。分析結果。
slb負載隻能進行load負載，無法進行當機備援。
cache緩存設定太小，1g記憶體容量導緻記憶體溢出，建議修改為4g。
使用http協定性能不佳。早上4點30進行少量代碼優化後，業務直接不可用，環境出現當機無法修複；快速進行快照恢複，5分鐘内恢複3台業務機，雲産品的優勢盡顯。
使用者log日志撐滿系統盤，并且一直不知這台雲主機還有資料盤。我們要做反思，幫助使用者進行挂盤及日志遷移至資料盤，減少單盤的io壓力。
③ web伺服器資料同步，發現伺服器io和cpu壓力過大。
加入inotify機制，由檔案增量同步，變更為檔案系統的變化通知機制。将冷備及4台備用web機器使用該方式同步，目前，檢視内容分發主機io和cpu使用率已恢複正常範圍。
同步推送時間，根據伺服器的負載，進行調整同步時間，已修改為2分鐘。
由于備份量大，适時進行全量同步。
新增4台備用機，已關閉apache 端口 自動從slb去除，作為冷備。
④ 由于目前單點使用者登入入口存在架構單點當機風險，進行登入和未登入風險驗證，确認，如使用者已登入後，登入業務系統出現當機，進行簡單的頁面點選切換，不受影響。
⑤ 記憶體優化
如圖22所示，按照jvm記憶體管理模式，調整系統啟動參數。如果一台ecs部署一台伺服器，建議不要選擇預設的jvm配置，應該設定記憶體為實體記憶體的一半，同時設定相應的ytc和fgc政策，觀察old區變化，避免大量full gc，建議full gc頻率大于1小時，同時gc時間小于1秒鐘。
圖22 記憶體優化
3.4.3 架構優化
單點登入服務修改為slb；
檢索 修改為 slb；
内容管理雲平台雲伺服器實作行檔案差異同步，同時冷備；
新增4台web機器5.5總結。
最終優化後的網站頁面性能滿足測試要求，優化前後的對比如表15、表16所示。
門戶首頁:
表15 架構優化前後的對比
備注：伺服器的cpu達到100%其實是一個好現象，說明我們的邏輯全部走到了資源消耗上，而不是由外部其他邏輯限制或blocked，這種現象帶來的好處就是，可以集中精力從減少代碼的資源消耗上解決問題，帶來性能的改善；
其次，實在無法優化也可以增加機器台數，通過橫向擴充讓性能成倍的提高，這也是用成本換性能的方法。當然，前提是架構上支援負載均衡的分布式架構。
其他分頁見表16。
表16 并發使用者數達到500後的三項資料
● 3.5 遺留問題和風險
時間原因，測試頁面有限，有些頁面沒有測試覆寫到，比如背景頁面。
登入系統存在記憶體風險，由于使用者的緩存資訊仍然存在單點問題，是以風險較大，同時系統壓力不滿足要求，并發較高，存在crash風險，未來得及發現瓶頸所在。徹底解決必須使用ocs等緩存系統改造，同時優化資料庫。
iframe架構造成使用者體驗不好，需要改進，換成異步js接口方式。
背景同步系統對資源消耗影響較大，需要持續優化。
應該提供開發和測試進行自主壓測、分析、評估，同時提供統一的測試報告，保證各部分子產品的性能，整合起來才能保障整個門戶網站的性能。
cpu優化還需要繼續分析跟進，目前隻是增加機器資源降低風險，成本較高。
上線釋出應該具備統一的回歸驗證機制，并且日常需要持續優化，避免由于後期代碼的改動導緻性能下降。