一種正規的性能調優方法：基于等待的調優

　　企業java應用的性能調優是一項艱巨的、有時甚至是徒勞的任務，這是由現代應用的復雜性和缺少正規的調優方法導致的?，F代企業應用與十年前的應用相比差距很大，如今這些應用支持多輸入、多輸出、復雜的框架和業務處理引擎。而十年之前，基于web的企業應用只是通過網絡瀏覽器獲得輸入信息，然后與數據庫或者遺留系統交互進行后臺處理，最后把輸出結果返回給瀏覽器(HTML)?，F在，輸入信息可以來自HTML瀏覽器、富客戶端、移動設備或者網絡服務，它可以跨越運行在不同架構下的servlets或者門戶容器，這反過來又可能調用企業bean，外部web服務或者把處理委托給業務規則引擎。每一個這樣的組件都可能與內容管理系統、緩存層、眾多數據庫和遺留系統交互。輸出的信息通常以獨立于展現層的形式保存，隨后轉化為HTML、XML、WML或者其他任意客戶端需要的格式?，F代應用比過去包含更多移動部分和“黑盒子”，這對性能調優提出了巨大的挑戰。

　　相關廠商內容

　　大型網站數據庫架構演變：沃趣科技CEO陳棟

　　優化您的數據庫與時間，實現更高性能

　　《白帽子講Web安全》，“道哥的黑板報”，吳翰清：重新定義WAF

　　虛擬化技術自動化測試環境部署：EMC高級軟件工程師邵育亮

　　持續集成與持續交付專家喬梁：近十年實戰項目案例之深度剖析

　　相關贊助商

　　QCon全球軟件開發大會2013，北京國際會議中心，4月25~27日,最后報名中詳情請點擊!

　　除了復雜性提高，性能調優技術其藝術性要大于科學性，還因為大多數性能調優指南都側重于性能指標，有時晦澀難懂，也可能影響用戶體驗。本文嘗試把性能調優活動變成一種“科學”范疇內的行為，提供了一種可重用的關注用戶體驗的方法，利用“等待點”(也就是應用中引起某請求等待的部分)分析應用架構?？傊?，基于等待的調優方法允許性能工程師們通過優化用戶體驗快速實現可度量的性能提高。

　　性能調優過程

　　在詳細介紹基于等待調優和等待點分析方法之前，本節首先對有效的性能調優過程做一個概述。性能調優可以簡單的概括為四步：

　　負載測試

　　容器調優

　　應用調優

　　迭代

　　像大多數計算機科學一樣，性能調優是一個迭代的過程。首先，創建一個合適的負載測試，其中包含了均衡的、具有代表性的服務請求，這都是容器調優實踐可以滿足的。隨著容器被不斷調優和測試壓力的增大，應用程序的瓶頸逐漸顯現出來。隨著應用的瓶頸被定位和解決，應用行為會發生變化，這就要求容器再次調優。在容器和應用之間的迭代過程會一直進行到性能到達可以接受的條件(或者直到項目已經到期必須發布時)。

　　負載測試方法

　　啟動一個性能調優實踐的先決條件是創建一整套合適的負載測試集合。每一個負載測試必須滿足以下兩點：

　　代表性，必須體現最終用戶的業務場景(或期望的場景)

　　均衡性，必須符合最終用戶不同行為的比例分配

　　也就是說，負載必須能夠按照最終用戶的實際操作比例來模擬用戶動作。為了說明均衡最終用戶動作的重要性，請看下面這個例子：在保險索賠部門，員工執行以下操作：

　　用戶上午八點登陸系統。

　　上午每人平均處理五個索賠請求。

　　大約80%的用戶忘記在吃飯之前注銷賬號，導致session過期。

　　午飯后，用戶重新登錄系統。

　　下午每人平均處理五個索賠申請。

　　下班之前生成兩個報告。

　　80%的用戶回家前注銷賬號。

　　這個例子是一個真實應用的簡化版，但是它足夠在這些服務請求建立一個平衡。這個場景展現的均衡是：兩次登陸，十次索賠處理，兩次報告和一次注銷。

　　如果負載生成器把壓力均勻分布在不同的服務請求上又會怎么樣呢?在本例中，用戶登陸和注銷功能會接收與處理與理賠請求相同的負載。如果是1000個并發用戶，登陸功能會很快崩潰，導致企業投資建立一個能夠處理這種負載的登陸組件，而實際上這種負載根本不會發生。更糟糕的是，本例中由于最大的瓶頸看似存在于登陸功能上，所以調優的努力會側重該功能，而忽視索賠處理功能?？傊?，一個非均衡的負載可能導致調優過程錯誤的關注于支持那些絕不會發生的負載的組件，而不是那些真正需要調優的部分!

　　判斷一個負載對于應用是均衡的和代表性的標準，對于測試一個已存在的應用(或者一個新版本)還是一個全新的應用是不同的。

　　已存在應用

　　已存在應用跟一個全新應用相比，一個明顯的優點是：真實的用戶行為可以在實際生產環境中觀察獲得。根據請求的本質和它們如何被應用定義，可以通過兩個選擇定義最終用戶行為：

　　訪問日志

　　最終用戶體驗監視器

　　對于大多數基于web的應用來說，訪問日志提供了足夠的資源分析服務請求的本質和它們的均衡關系。Web服務器可以配置成抓取最終用戶請求信息并存儲在一 個日志文件中，稱之為“訪問日志”(因為該文件通常命名為“access.log”)。使用訪問日志定位用戶行為的關鍵是應用交互需要能夠通過不同的 URI來區分。例如，如果之前例子的動作采用類似“/login.do”、“/processClaim.do”、“/logout.do”的URI，那 么我們可以非常容易的在訪問日志中發現這些行為并確定它們的比例。更進一步，通過最頻繁的URI來排序訪問日志可以快速發現占比例前n%的的若干請求，這 個“n”%應該在80%左右。

　　訪問日志是文本文件，可以手動檢查(不是一個很有效率的任務)，可以通過編程解析，也可以通過工具來分析。對此有很多商業解決方案，不過Quest Software有一個產品Funnel Web Analyzer，雖然多年以前已經終止開發，但是由于其很受歡迎的命令，公司就作為將其作為自由軟件重新發布。Funnel Web Analyzer可以分析大多數訪問日志并顯示用于創建合適負載測試的信息。

　　一些應用不像上面提到的那樣簡單，其用戶交互無法很容易的通過一個URI來定位。例如，考慮一個包含前端控制器servlet的應用，該servlet接受一個XML有效信息——并且其業務處理邏輯就存在于該信息中。在本例中，需要另外的工具來偵測其有效信息以判斷其符合哪個業務場景。這可以通過使用 servlet過濾器或者一個稱為最終用戶體驗監視器的硬件設備來完成。

原文轉自：http://www.infoq.com/cn/articles/Wait-Based-Tuning-Steven-Haines