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

　　不管用戶行為是如何獲得的，它都是開始任何性能調優實踐之前的關鍵先決條件。

　　全新應用

　　由于全新的應用沒有任何最終用戶行為可以分析，所以對我們提出了一個獨特的挑戰。定位新應用的用戶行為需要三個步驟，如圖1所示。

　　圖 1 評估新應用的最終用戶行為

　　第一步，評估最終用戶應該會做什么。這步是“猜一猜”的正式說法，但應該是一個經過培訓的猜測過程。評估結果應該來自于以下雙方的討論：應用業務負責人和應用技術負責人。應用業務負責人，通常是一個產品經理，負責細化最終用戶應該如何使用該應用程序——例如，他可能報告說最終用戶會登陸、處理五個索賠請求、過期、處理五個索賠請求、生成兩個報告、然后注銷。應用技術負責人，一般是架構師或是技術lead，負責把業務交互的抽象列表翻譯成用于生成負載測試的技術步驟——例如，他可能報告說登陸通過“/login.do” URI完成而處理一個索賠請求需要五個URI。這些人(或者小組或者一些大型項目里的委員會)應該一起提供足夠的信息來建立一個基準負載測試。

　　我們建立負載測試，用其調整應用和容器，應用程序部署到生產環境中，這一切做完之后，調優工作并沒有結束。下一步是驗證負載測試集。這通常是一個多階段的活動：

　　冒煙測試驗證：在實際運行的一兩周之內驗證原先的評估值是否符合真正生產環境下最終用戶的行為。這步驗證是為了確認在評估過程中沒有明顯的錯誤。

　　生產驗證：一些應用需要用戶花時間才能形成統一的使用方式。這個適應的時間長短因應用而異，可能是一個月或者一個季度，不過一旦用戶的行為穩定下來，就需要驗證最終用戶行為是否與評估一致。

　　回歸驗證：最好在應用的生產周期中階段性的驗證用戶行為，以防止用戶行為改變或者引入新的功能或工作流導致用戶行為改變。

　　最后一步，也是經常被忽視的一步，就是反思。根據實際用戶行為來反思評估的精確性是很重要的，因為只有通過反思，用戶行為才能更便于理解，評估在以后的應用中才能得到提高。沒有反思，相同的錯誤會一犯再犯，最終會增加調優的工作量。

　　基于等待的調優方法

　　建好了負載測試，接下來就是決定把調優精力放在何處。大多數調優指南都會提到“性能比率”或者度量之間的關系。例如，某調優指南可能強調說緩存命中率應該達到80%或者更高，因此負載測試應用時調整緩存大小直到命中率達到80%。然后處理列表上的下一個度量值，但是不要忘記驗證調整新的參數不會影響之前已經調好的其他參數。

　　這項工作不僅困難而且效率很低。例如，調整緩存命中率到80%可能是件好事，但是存在一些更重要的問題：

　　該應用如何依賴于緩存(與該緩存交互的請求比例是多少)?

　　這些請求對應用中的其他請求有多大影響力?

　　被緩存的條目的本質是什么?它們真的需要緩存嗎?

　　基于等待的調優方法提出了一個新的思想，即分析應用的業務交互和實現這些交互的底層結構，然后優化這些業務交互的處理。第一步是分析應用的架構以定位實現業務請求的相關技術。每一個技術代表一個“等待點”，或者說在應用的這個地方，請求可能需要等待一些事情才能繼續處理。例如，如果一個請求執行了一次數據庫查詢，則它必須從連接池中獲取一個數據庫連接—如果連接池里沒有可用的連接，則該請求必須等待直到有連接可用。同樣，如果某請求調用了一個web服務，而那個web服務維護了一個請求隊列(對應一個線程池處理請求)，這會潛在的導致請求等待直到一個處理線程可用。

　　從以上稱之為等待點分析的方法中，可以定位兩種類型的等待點：

　　基于層次的等待點

　　基于技術的等待點

　　本節首先概述了基于等待點的架構分析方法，然后分別研究了不同類型的等待點。

　　等待點架構分析

　　從上面討論中得出的最重要的結論就是性能調優必須在應用架構的環境中執行。這也是調優性能比率為何如此低效的一個原因：主觀的調整一個性能參數到一個最佳值，對應用可能是好事也可能是壞事——因為這可能會也可能不會有利于最終用戶體驗。

　　基于等待點的分析是一個分析應用中主要請求處理路徑的過程，借此定位潛在影響該請求可能會等待的資源。在等待點分析實踐中最有效的辦法是定位并標出應用中核心處理路徑。這包括一個請求可能訪問的所有層次、請求交互的所有外部服務、被做成池的所有對象和全部緩存對象。

　　基于層次的等待點

　　一個請求穿過一個物理層，比如在web層和業務層之間切換，或者調用外部服務器，比如web服務，每當這種時候，都意味著伴隨著轉換，這里存在一個隱式等待點。如果服務器在某一時刻只處理單個請求是沒有效率的，因此他們使用了多線程方法。典型的，一個服務器在某個socket端口監聽訪問的請求——每當收到一個請求它就會把請求放在隊列中，然后返回監聽其他請求。請求隊列對應著一個線程池，負責從隊列中提取請求并處理。圖2描述了對于三層結構(web服務器、動態web層和業務層)的執行過程。

　　圖 2 基于層次的等待點

　　因為請求穿越層次的動作會引起請求隊列，由相應的線程池處理，這種線程池也是一個潛在的等待點。每一個線程池的大小的調優必須基于以下考慮：

　　池必須足夠大使得訪問的請求無需不必要的等待一個線程。

　　池不能大到耗盡服務器。過多的線程會迫使服務器花費大量時間用于在不同的線程上下文中切換，真正處理請求的時間反而更少了。這種情況通常表現為CPU使用率很高，但是處理請求的吞吐量卻降低了。

　　池的大小不能透支與之交互的后臺資源。例如，如果數據庫對于單個服務器只支持50個請求，那么服務器不應該向數據庫發送超過50個數量的請求。

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