Posted on 2012-04-15 16:37
zljpp 閱讀(169)
評論(0) 編輯 收藏
? ? 基于等待的調優方法
??? 建好了負載測試，接下來就是決定把調優精力放在何處。大多數調優指南都會提到“性能比率”或者度量之間的關系。例如，某調優指南可能強調說緩存命中率應該達到80%或者更高，因此負載測試應用時調整緩存大小直到命中率達到80%.然后處理列表上的下一個度量值，但是不要忘記驗證調整新的參數不會影響之前已經調好的其他參數。
??? 這項工作不僅困難而且效率很低。例如，調整緩存命中率到80%可能是件好事，但是存在一些更重要的問題：
????● 該應用如何依賴于緩存（與該緩存交互的請求比例是多少）？
????● 這些請求對應用中的其他請求有多大影響力？
????● 被緩存的條目的本質是什么？它們真的需要緩存嗎？
??? 基于等待的調優方法提出了一個新的思想，即分析應用的業務交互和實現這些交互的底層結構，然后優化這些業務交互的處理。第一步是分析應用的架構以定位實現業務請求的相關技術。每一個技術代表一個“等待點”，或者說在應用的這個地方，請求可能需要等待一些事情才能繼續處理。例如，如果一個請求執行了一次數據庫查詢，則它必須從連接池中獲取一個數據庫連接—如果連接池里沒有可用的連接，則該請求必須等待直到有連接可用。同樣，如果某請求調用了一個web服務，而那個web服務維護了一個請求隊列（對應一個線程池處理請求），這會潛在的導致請求等待直到一個處理線程可用。
??? 從以上稱之為等待點分析的方法中，可以定位兩種類型的等待點：
????● 基于層次的等待點
????● 基于技術的等待點
??? 本節首先概述了基于等待點的架構分析方法，然后分別研究了不同類型的等待點。
??? 等待點架構分析
??? 從上面討論中得出的最重要的結論就是性能調優必須在應用架構的環境中執行。這也是調優性能比率為何如此低效的一個原因：主觀的調整一個性能參數到一個最佳值，對應用可能是好事也可能是壞事——因為這可能會也可能不會有利于最終用戶體驗。
??? 基于等待點的分析是一個分析應用中主要請求處理路徑的過程，借此定位潛在影響該請求可能會等待的資源。在等待點分析實踐中最有效的辦法是定位并標出應用中核心處理路徑。這包括一個請求可能訪問的所有層次、請求交互的所有外部服務、被做成池的所有對象和全部緩存對象。
??? 基于層次的等待點
??? 一個請求穿過一個物理層，比如在web層和業務層之間切換，或者調用外部服務器?，比如web服務，每當這種時候，都意味著伴隨著轉換，這里存在一個隱式等待點。如果服務器在某一時刻只處理單個請求是沒有效率的，因此他們使用了多線程方法。典型的，一個服務器在某個socket端口監聽訪問的請求——每當收到一個請求它就會把請求放在隊列中，然后返回監聽其他請求。請求隊列對應著一個線程池，負責從隊列中提取請求并處理。圖2描述了對于三層結構（web服務器、動態web層和業務層）的執行過程。
圖 2 基于層次的等待點
??? 因為請求穿越層次的動作會引起請求隊列，由相應的線程池處理，這種線程池也是一個潛在的等待點。每一個線程池的大小的調優必須基于以下考慮：
????● 池必須足夠大使得訪問的請求無需不必要的等待一個線程。
????● 池不能大到耗盡服務器。過多的線程會迫使服務器花費大量時間用于在不同的線程上下文中切換，真正處理請求的時間反而更少了。這種情況通常表現為CPU使用率很高，但是處理請求的吞吐量卻降低了。
????● 池的大小不能透支與之交互的后臺資源。例如，如果數據庫對于單個服務器只支持50個請求，那么服務器不應該向數據庫發送超過50個數量的請求。
??? 服務器線程池的最佳尺寸的標準是：對受限制的依賴資源產生足夠的負載—最大化它們的使用率而不讓其透支。下面的“后退調優”一節有更多調整受限制資源池大小的內容。
已有 0 人發表留言，猛擊->>這里<<-參與討論
ITeye推薦