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

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

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

　　• 該應用如何依賴于緩存（與該緩存交互的請求比例是多少）？

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

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

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

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

　　• 基于層次的等待點

　　• 基于技術的等待點

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

　　等待點架構分析

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

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

原文轉自：http://www.anti-gravitydesign.com