一種正規的性能調優(yōu)方法：基于等待的調優(yōu)

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

　　相關(guān)廠(chǎng)商內容

　　大型網(wǎng)站數據庫架構演變：沃趣科技CEO陳棟

　　優(yōu)化您的數據庫與時(shí)間，實(shí)現更高性能

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

　　虛擬化技術(shù)自動(dòng)化測試環(huán)境部署：EMC高級軟件工程師邵育亮

　　持續集成與持續交付專(zhuān)家喬梁：近十年實(shí)戰項目案例之深度剖析

　　相關(guān)贊助商

　　QCon全球軟件開(kāi)發(fā)大會(huì )2013，北京國際會(huì )議中心，4月25~27日,最后報名中詳情請點(diǎn)擊!

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

　　性能調優(yōu)過(guò)程

　　在詳細介紹基于等待調優(yōu)和等待點(diǎn)分析方法之前，本節首先對有效的性能調優(yōu)過(guò)程做一個(gè)概述。性能調優(yōu)可以簡(jiǎn)單的概括為四步：

　　負載測試

　　容器調優(yōu)

　　應用調優(yōu)

　　迭代

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

　　負載測試方法

　　啟動(dòng)一個(gè)性能調優(yōu)實(shí)踐的先決條件是創(chuàng )建一整套合適的負載測試集合。每一個(gè)負載測試必須滿(mǎn)足以下兩點(diǎn)：

　　代表性，必須體現最終用戶(hù)的業(yè)務(wù)場(chǎng)景(或期望的場(chǎng)景)

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

　　也就是說(shuō)，負載必須能夠按照最終用戶(hù)的實(shí)際操作比例來(lái)模擬用戶(hù)動(dòng)作。為了說(shuō)明均衡最終用戶(hù)動(dòng)作的重要性，請看下面這個(gè)例子：在保險索賠部門(mén)，員工執行以下操作：

　　用戶(hù)上午八點(diǎn)登陸系統。

　　上午每人平均處理五個(gè)索賠請求。

　　大約80%的用戶(hù)忘記在吃飯之前注銷(xiāo)賬號，導致session過(guò)期。

　　午飯后，用戶(hù)重新登錄系統。

　　下午每人平均處理五個(gè)索賠申請。

　　下班之前生成兩個(gè)報告。

　　80%的用戶(hù)回家前注銷(xiāo)賬號。

　　這個(gè)例子是一個(gè)真實(shí)應用的簡(jiǎn)化版，但是它足夠在這些服務(wù)請求建立一個(gè)平衡。這個(gè)場(chǎng)景展現的均衡是：兩次登陸，十次索賠處理，兩次報告和一次注銷(xiāo)。

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

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

　　已存在應用

　　已存在應用跟一個(gè)全新應用相比，一個(gè)明顯的優(yōu)點(diǎn)是：真實(shí)的用戶(hù)行為可以在實(shí)際生產(chǎn)環(huán)境中觀(guān)察獲得。根據請求的本質(zhì)和它們如何被應用定義，可以通過(guò)兩個(gè)選擇定義最終用戶(hù)行為：

　　訪(fǎng)問(wèn)日志

　　最終用戶(hù)體驗監視器

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

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

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

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