老李分享：性能優化的境界

老李分享：性能優化的境界

 

  這篇文章是關於網站性能優化體驗的，性能優化是一個複雜的話題，牽涉的東西很是多，我只是按照個人理解列出了性能優化整個過程當中須要考慮的種種因素。點到爲止，包含的內容以淺顯的介紹爲主，若是你有看法能告知我那再好不過了。不管如何，但願閱讀它的你有所收穫。

 

我眼中的網站性能問題都反映了一個網站的「Availability」（中文叫作可用性，可是這個翻譯也不足夠達意），以往個人認識是，這個網站若是所有或者部分不可用，那是功能問題，可是若是響應慢、負載差，這纔是性能問題；但是後來我逐漸意識到，性能問題涵蓋的範圍更廣，我還無法給出一個準肯定義，可是許多非業務邏輯錯誤引發的網站問題均可能能夠算作性能問題，好比可擴展性差，好比單點故障問題。

 

在網站性能優化的最初階段，也就是所謂的「第一重境界」，作局部的定位、分析和修正，考慮的僅僅是「優化」，這也是初涉性能優化問題的大多數人的認識。在問題發生之後，發現它和業務邏輯沒有太大關係，就開始嘗試尋找問題產生的緣由並加以解決。

 

不管是網站無響應仍是響應緩慢，仍是響應曲線異常波動，好比，能夠圍繞CPU的使用問本身這樣幾個問題：

 

• 從CPU使用看系統是否繁忙？
• 若是系統繁忙，系統在作什麼，爲何？（典型問題：HashMap不安全併發致使的死循環）
• 若是系統空閒，那麼瓶頸在哪裏？（典型問題：IO無響應）
• 若是響應波動，是否存在週期，週期是什麼？（典型問題：鏈接迅速佔滿，每一週期批量超時斷開一批）
• 若是響應波動，性能到波谷時系統在作什麼？
• 是否有背景CPU使用？（即無壓力下觀察CPU的使用狀況。典型問題：正執行的定時任務佔用過多系統資源）

在這些問題中，狀況雖然變幻無窮，簡單地說，CPU的使用是核心，CPU使用率高，說明系統資源被充分利用，可能系統在實實在在地作事，反之，須要尋找其餘瓶頸。經過結合進程、線程的快照，來初步肯定問題的範圍。CPU使用率低的狀況居多並且容易定位，只須要尋找其餘的系統瓶頸；CPU佔用率偏高的問題每每比較不容易定位，雖然也有一些辦法。關於具體性能問題的定位技術，這裏不着過多筆墨，後續有機會詳細介紹。

 

對於一個剛開始作性能優化的網站系統，下面的事情不妨都作一作，會有立竿見影的效果：

 

• 對於使用的成熟的技術，技術社區、官方文檔，每每會給出這種技術的白皮書或者優化指導，請參考。好比 Struts2的官方性能調優指南、Java6性能優化白皮書。
• 平臺和虛擬機調優。對於使用平臺和虛擬機的項目來講，這是必需要作的，一個JVM的參數能夠對系統有顯著的影響。好比Linux下鏈接管理的參數，JVM關於堆大小分佈的參數等等。
• 前端審查。這裏的審查指的是經過Page speed、YSlow等工具，以及一些業界通用的法則和經驗（好比yahoo的若干條前端性能優化法則）來評估現有頁面的問題。

若是你須要系統的指導，不妨參考這張圖（點此下載大圖和mmap文件：Site_Performance_Practice_Road_Map）：

 

從使用的工具上說，性能問題的定位很大程度上是面向操做系統、虛擬機系統的問題定位。從問題定位的時機上說，又能夠分爲：

 

• 截取型：截取系統某個層面的一個快照加以分析。好比一些堆棧切面和分析的工具，jstack、jmap、kill -三、MAT、Heap Analyser等。
• 監控型：監視系統變化，甚至數據流向。好比JProfiler、JConsole、JStat、BTrace等等。
• 驗屍型：系統已經宕機了，可是留下了一些「罪證」，在過後來分析它們。最有名的就是JVM掛掉以後可能會留下的hs_err_pid.log，或者是生成的crash dump文件。

瞭解到這裏，再給出這樣幾個常見問題定位的場景：

 

第一類：請求無響應，瀏覽器始終處於等待狀態。

定位方法：kill -3或者jstack先分析線程堆棧，找到當前block的線程。

常見於：外部接口調用無返回或者網絡IO阻塞無響應；死鎖；死循環；……。

 

第二類：宕機，進程掛掉。

定位方法（這一類問題廣泛比較難定位）：

    （1）尋找hs_err_pidxxx.log這樣的JVM日誌

    （2）使用JVM參數在JVM crash時寫入到dump文件中

    （3）catalina.out中尋找最後的日誌

    （4）宕機前環境數據採集

常見於：JDK bug（數次遇到過JIT引發的這一類問題）；調用dll的問題；……

 

第三類：請求響應時間長。

定位方法：kill -3或者jstack先分析線程堆棧，看線程大都停留在什麼操做上面，再細化分析。

常見於： 內存不足，可見到連續的Full GC；網絡擁塞；LoadRunner等壓力客戶端瓶頸；數據庫瓶頸，可進一步分析DB快照；……

 

第四類：TPS低；TPS逐漸下降；TPS振盪幅度過大。

定位方法（這一類問題最多見，定位的方法也最複雜）：

首先觀察在壓力增大時，CPU使用率可否上去，若是不能上去，尋找其餘瓶頸：網絡/內存/磁盤/……；CPU

使用率上去了，觀察在無壓力時，是否有背景CPU使用（例若有後臺定時任務線程消耗了大量CPU資源），若是沒有，那能夠嘗試JProfiler等工具結合線程分析、業務分析，尋找熱點。

常見於：其餘業務線程干擾；內存泄露；鏈接句柄用完；緩存命中率低下……

 

好，暫時說到這裏，下面來看第二重境界。達到這重境界意味着已經可以跳出「過後優化」的侷限了，在設計和編碼的過程中，可以正式和全面地考慮性能的因素，好比：

 

• 減小使用時間敏感的容器管理，而使用容量或數量敏感的容器管理。好比我往一個緩衝裏面存放若干數據，一種設計是每10分鐘flush入庫一次，還有一種設計是數據到達10M大小的時候flush入庫一次，一般狀況下，你以爲哪一個方案更可靠？
• 線程的統一管理使用。個人經驗是，10次對線程建立或者線程池的使用，每每就有5次是會出問題的。
• 避免使用同步Ajax。同步Ajax會形成瀏覽器假死，直至響應返回。
• 分析對同步、鎖的使用。即使在一些有名的開源庫中，咱們也不止一次發現過不合理的同步設計，N多數據，單一的全局同步塊（這是一種性能設計層面上的「中心化」），結果它就成爲了瓶頸，改動還不容易下手，很麻煩。

對於不成熟的團隊，建議能安排有經驗的程序員把關設計文檔和編碼中的性能問題，把常見的問題列出來參考學習。

 

達到第二重境界還有一個明顯的特徵，就是在軟件流程的前中期就開始作性能目標的論證和性能問題的驗證：

 

• 性能切面分析。這指的是在系統設計初期，爲了評估一個系統的性能表現，作出一個性能相似的系統原型，並對其作性能測試和評估，這時候由於性能問題而涉及到方案的變動，影響較小。據我所知，可以作到這一點的項目極少。在大多數團隊中，依賴於架構師和掌握話語權的設計者依靠經驗來避免性能問題帶來的大的方案變動（或者，乾脆摔一次跤，再進行痛苦的「重構」）。
• 性能的自動化測試驗證。這一步必須伴隨着Coding進行纔有較大的意義，以便儘早發現性能問題。
• 設計和代碼層面的評審。其實功能問題考慮得多、暴露得早，真正有危險的每每都是那些被忽視的非功能性問題，好比性能問題。

 

最後是第三重境界。達到這重境界的團隊可以在早期規劃構想階段就將性能做爲一個必備因素包含在內，這可不是隨口說說的經驗的估計，而是要有數據驅動的理論設計，好比作性能建模，根據市場大小、業務量、服務等級等等計算出性能的具體指標，而且在此要求下作合理的架構設計。

 

這裏涉及的東西有不少，除了數據，還須要有大量的思考，對於一個網站來講，不妨問問以下的問題：

 

• 數據量會有多大，我該設計什麼樣的存儲？一致性的要求又如何？
• 實時性要求是怎麼樣的？用戶能夠接受多少時間的數據延遲？
• 網站須要考慮到什麼程度的可伸縮性？
• 哪些流程的數據處理有性能風險，數據量是什麼級別的？怎麼解決這個問題？
• 主要的業務時間消耗是怎樣的，我須要設計怎樣的業務流來知足？

全部的性能問題和其餘一切非功能性問題同樣，都是必定程度上的trade off，因此越優秀的設計者越須要思考，來規劃這些問題的解決方案，在規劃中由於性能問題而涉及到的因素有哪些，太多太多了。

而要解決這樣在規劃中就預料到的性能問題，也有許多內容值得討論，下面列出一些供參考：

 

• 一、集羣組網：這是最基本的橫向擴展的方式，把單節點的壓力經過負載均衡分擔到多個節點下，提升了系統負載能力的同時，亦提升了穩定性。
• 二、反向代理：一個大型的互聯網網站不能不引入反向代理對靜態資源的處理，Servlet容器用來處理靜態圖像和文本是很是奢侈的，Apache、Nginx、Squid都是優秀的解決方案。
• 三、頁面靜態化：互聯網應用「緩存爲王」，這多是數種方案中能帶來惠利最明顯的一種，經過靜態頁面的生成和訪問，有效地下降了系統負載。Web2.0的應用緩存命中率一般要稍差。
• 四、數據庫優化：用戶的訪問難以知足了，數據庫硬件設備的強化之外，從最基本的拆表、SQL調優，到縱向和橫向的分庫幾乎成爲必不可少的解決辦法，或者更換廉價存儲解決方案，使用NoSQL數據庫等等。
• 五、CDN：CDN指的是內容分發網絡，經過網絡的廣域層面對用戶需求的分擔，避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，提升用戶體驗。
• 六、分佈式存儲：海量信息的爆炸，須要廉價存儲的解決方案，Web2.0的數據尤甚。分佈式存儲系統能夠保證大吞吐量的數據讀寫和海量數據存儲，實時性就顯得不那麼重要了。
• 七、數據緩存：這裏的數據緩存和頁面緩存區分開，數據緩存一般包括持久層層面的緩存和外部接口調用的緩存，數據緩存能夠減少各種I/O調用，增長用戶響應的平均時間。
• 八、功能性集羣：初步的集羣是對等的，這類集羣方式簡單可控；可是隨着產品日益複雜化，用戶訪問壓力日益增大，單純的對等集羣解決不了全部的問題，且產生大量冗餘處理邏輯，使用功能性集羣能夠將完成不一樣功能的節點規約在一塊兒。
• 九、頁面分區：對一個大型網站，這是必不可少的。目的就是要進行頁面靜態化，並將動態和靜態的區域分離開，以便在用戶訪問的時候，只作簡單的聚合操做。
• 十、頁面片斷的生成和頁面的聚合相剝離：許多頻繁訪問的相對靜態的頁面片斷一般只須要的定時或事件觸發的狀況下才生成一次，甚至能夠放在系統壓力較輕的夜間生成。用戶每次請求時只須要將靜態的頁面片斷聚合成一個完整的頁面（亦須要添加上動態的部分）便可。
• 十一、隔離：對複雜系統的隔離和備份主要是爲了解決穩定性問題，保持每個單元的「簡單」，化整爲零，更容易將單元獨立開發、產品化。
• 十二、聚合方式的改進：引入高性能的服務端頁面聚合方式（通過驗證，常規SSI、ESI的性能存在缺陷）；甚至客戶端聚合：將展現模板送到客戶端，再經過Ajax請求將JSON（或其它簡單格式）數據流送到客戶端，在客戶端使用Ajax聚合出最終的頁面來，好處在於將服務端的壓力分擔到客戶端。
• 1三、組件服務化：服務化的好處在於易於將組件的處理並行化，增長總體的響應速度。模式能夠遵循SOA的方式，系統中使用高性能的ESB來進行服務編排和任務分派。

要達到第三重境界還要可以預測性能問題。這就須要成熟的監控體系，監控系統的變化，儘快作出反應。

 

好比國內發生了重大事件，用戶量陡增，監控系統可以及時識別出用戶量監控曲線一個很是明顯的跳躍過程（好比持續事件超過某個值，且曲線斜率超過某個值），發出告警，而且自動擴容來應付潛在的風險。這些，都是創建在常規的業務運營數據收集基礎之上的，而後須要作數據挖掘，給出關鍵點。

 

再好比互聯網應用「緩存爲王」。對於緩存的設計，甚至很大程度上決定了應用的成敗（若是你頗有錢，靠大量的CDN這種很是規路線的另說，呵呵）。緩存的設計須要考慮到緩存的大小、分級、隊列、命中率計算、生命週期、更新換頁、數據分發、數據一致性和數據持久化等等問題，這些東西每每被不少只重視那些頁面展現效果和功能的人所忽視，但若是你是優秀的設計者，你須要積累這些思考。

 

Think big。有這樣一個真實的例子，咱們曾經發現頁面模板的OGNL性能不高（兩次反射之故），遂在項目中把大部分OGNL表達式都改爲了EL表達式，花了不少時間精力，性能也確實提升了，可是能提升多少呢？大概只有30%，這是一種細水長流的改進，對系統的破壞性不大，可是收效也不足以使人沾沾自喜，還失去了一些OGNL的靈活性。以後，咱們換了一個思路，從大局入手，給頁面劃分區域，定製緩存框架，引入頁面緩存能力，雖然整套方案有些複雜，可是這種架構上的進化，因爲頁面的生成或者部分生成直接命中了緩存文件，性能一下有了飛躍，提升了600%~800%。這就是Think big，從大處着想，見獲得工程大塊的結構，須要足夠的視野、足夠的經驗和積累，能夠帶來顯著的效果。

 

一般系統容量的設計都會要求到峯值容量以上，若是是像秒殺、搶購之類對性能要求很是高的系統，每每還存在一個問題：設計了這麼大的容量，平時大部分時間業務量都比較小，這些資源浪費怎麼辦？（題外話：這大概也是Amazon涉足雲存儲和雲計算的初始原因吧）

 

咱們來看這樣一個在性能驅動下架構變遷發展的例子：

初期，只有簡單的應用服務器和DB服務器分家，使用簡單的Jetty容器，系統的瓶頸在DB側。簡單就是美，網站剛剛運營，能訪問就是王道：

系統在發展中不斷地演化。

有一天發現用戶壓力愈來愈大，終於沒法承受了，系統屢屢到達崩潰的邊緣，在現有硬件和架構條件下很難支撐現有的業務，作出了這樣的改變：

在此次改變中，作了這幾件重要的事情：

• 一、引入了全頁面的緩存。互聯網應用緩存爲王，全頁面的緩存能夠起到立竿見影的效果。
• 二、把頁面展示抽象成爲「主題」，和頁面數據分離開來。而且，爲此，引入了「聚合」的概念，它爲之後的進一步發展打下了一個伏筆。
• 三、爲了緩解數據庫的瓶頸，使用了RAC方式作持久層的集羣。
• 四、對於JS、CSS、圖片等幾乎一成不變的靜態資源，引入反向代理，優先處理。

網站繼續安安靜靜地發展，悄悄地演化。

終於有一天，用戶訪問量激增，百萬級的PV達到了，WEB2.0業務也增長進來，緩存的命中率愈來愈低，CPU成爲了瓶頸，訪問異常緩慢。這一次，又要動刀了：

這一次的架構重構作了這麼幾件重要的事情：

• 一、靜態資源（特別是可供下載的文件），使用CDN緩解壓力。
• 二、把請求拆分紅主請求、異步數據請求和靜態資源請求，其中主請求僅僅是獲取頁面不變的部分（模板+靜態數據），動態的數據以異步JSON的方式獲取，並在瀏覽器端使用JavaScript聚合。這一步把某些聚合操做放置到了客戶端進行，緩解了服務端壓力。
• 三、真正將頁面的聚合展示和頁面的生成拆分開來，保證了用戶響應是快速的。
• 四、引入多層次緩存（內存中對象集合使用Memcached緩存，接口層面緩存報文，頁面緩存緩存文件等），同時，對於層次的劃分，容易將整個系統拆分紅若干個子部件獨立運做，簡單、獨立。
• 五、數據庫進一步拆分，讀寫分離。
• 六、頁面分塊。這是大型Web2.0網站共有的特色，一個頁面上每每總有那麼一部分是固定不變的，這些部分應當能以頁面片斷的形式緩存到磁盤上，每次頁面生成的時候只須要更關注變化的部分便可。

繼續、繼續……

訪問量增加了幾十倍，集羣的服務器也第一次達到了三位數，系統不穩定，速度從新落下，問題定位也無比困難，一切又開始撲朔迷離起來。

這一次，不可避免地又作了架構上的調整，首要的目標，是以隔離解耦的方式增長系統穩定性，同時，更便於產品化管理：

• 一、總體採用SOA方式佈局，按照功能劃分集羣，而且每一個功能集羣定義爲一個「服務」，內部採用REST風格的接口訪問服務。服務驅動和編制引擎（ESB角色）定時把能夠提早生成的靜態數據存放到共享存儲上。
• 二、清晰化聚合邏輯，靜態的數據儘可能在服務端聚合完成，減小客戶端數據請求的流量。
• 三、引入NOSQL數據庫和廉價存儲，適當放棄一致性，爲海量數據作妥協。
• 四、開發核心業務功能包部署引擎（基於OSGi），對於業務的定製，只須要按照功能包定義的格式開發，完成後可作到不重啓應用增長業務功能。

最後要說的是，如你所見，性能因素是一個網站系統發展的其中一個重要推進力，再細緻的思考也難以兼容那麼多未知的場景，不妨多在擴展性和兼容性上下下功夫，避免網站冷清痛苦，網站大熱更痛苦。