基于等待的性能調優方法

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

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

性能調優過程

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

1. 負載測試
2. 容器調優
3. 應用調優
4. 迭代

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

負載測試方法

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

• 代表性，必須體現最終用戶的業務場景（或期望的場景）
• 均衡性，必須符合最終用戶不同行為的比例分配

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

1. 用戶上午八點登陸系統。
2. 上午每人平均處理五個索賠請求。
3. 大約80%的用戶忘記在吃飯之前注銷賬號，導致session過期。
4. 午飯后，用戶重新登錄系統。
5. 下午每人平均處理五個索賠申請。
6. 下班之前生成兩個報告。
7. 80%的用戶回家前注銷賬號。

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

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

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