我的家園

? ? 基于技術的等待點

??? 基于層次的等待點考慮的是在不同服務器之間傳遞請求，而基于技術的等待點關注的則是在單個服務器中如何通過有效地內部工作來傳遞請求。基于層次的調優(yōu)，類似于IBM的隊列調優(yōu)，只是調整應用的有效第一步，如果忽略了調優(yōu)應用服務器的內部工作，則會對應用性能產生巨大的影響。這就類似于調整JDBC連接池以發(fā)送最佳數量的負載給數據庫，但是忽略了檢查執(zhí)行的SQL語句——如果查詢需要連接十個表單，每個表單有一百萬個記錄，則最佳負載可能是兩個連接，但是如果我們優(yōu)化了查詢，則數據庫可能支持二百個連接。深入研究應用服務器和應用使用的潛在技術，可能存在以下通用的基于技術的等待點：

????● 池對象（比如無狀態(tài)session bean或者其他應用放入池的業(yè)務對象）
????● 緩存設施
????● 持久化存儲?或外部依賴池
????● 通訊基礎設施
????● 垃圾收集

??? 大多數情況下，無狀態(tài)session bean池的大小被應用服務器優(yōu)化，不會是一個明顯的等待點，除非池大小被手工錯誤的配置了。但是也存在一些池對象必須手動配置大小——這些可能成為有效的等待點。當一個應用需要一個池化的資源，它必須從池里獲取一個資源實例，使用它，然后釋放給池。如果池太小，所有的對象實例都在被使用，則請求不得不等待一個實例可用。顯而易見，等待一個池化的資源會增加響應時間，如果越來越多的請求被堵塞在等待池化資源，會導致明顯的性能下降。另一方面，如果池很大，它可能消耗過多內存，對總體JVM的性能產生差的影響。池的最佳大小需要權衡，只能在對池的利用情況做徹底的分析才能決定。

??? 池化對象是無狀態(tài)的，這意味著應用從池中得到哪個實例都無所謂——任何實例都行。另一方面，緩存的對象都是有狀態(tài)的，也就是說當應用從緩存中請求一個對象時，它的目標是一個特定對象。舉一個很粗糙的類比說明一下區(qū)別：考慮人們生活當中兩種常見的活動：超市購物和接孩子放學。在超市中，任何收銀員都可以接待每一位顧客，無論顧客選擇哪位收銀員都可以順利結賬。因此收銀員可以池化。但是在接孩子放學時，每一個父母只想要他們自己的孩子，別的孩子是不行的。因此孩子可以被緩存。

??? 如前面所述，緩存提出了一個新的調優(yōu)挑戰(zhàn)。簡單說，緩存的目的是在本地內存中存儲對象，使應用可以隨時讀取它們，而不是在需要的時候才獲取他們。一個合適大小的緩存可以對通過遠程調用加載對象的行為提供明顯的性能改善。但是，一個不合適大小的緩存，可能產生明顯的性能阻礙。因為緩存維護有狀態(tài)的對象，所以重要的一點是在緩存中存儲最頻繁訪問的對象，同時保留額外的空間來處理非頻繁訪問對象。試想如果緩存太小，請求會怎樣：

??? 1、請求檢查緩存中是否存在某對象，結果失敗。
??? 2、請求需要查詢外部資源獲取對象數據。
??? 3、因為緩存通常維護最頻繁訪問的數據，所以這個新對象需要添加到緩存中（它正在被訪問）。
??? 4、但是如果緩存滿了，必須利用“最少最近訪問”算法選擇一個對象移除。
??? 5、如果緩存對象的狀態(tài)與外部資源不一致，則緩存對象移除之前必須更新外部資源。
??? 6、新的對象此刻添加到緩存中。
??? 7、新的對象最終返回給請求。

??? 這是一個低效的過程，如果大多數請求都要執(zhí)行這些步驟，那么緩存肯定會降低性能。緩存必須調整到足夠大以最小化緩存的“不命中率”，一次不命中意味著需要執(zhí)行前面提到的七個步驟，但是也不能太大導致占用太多JVM內存。如果緩存需要非常非常大才能滿足性能需要，那么最好是重新考慮被緩存對象的實質和它們到底是否值得緩存。

??? 類似對象池，外部資源池，比如數據庫連接池，也必須足夠大以滿足請求不會被迫等待池中的一個連接變?yōu)榭捎脿顟B(tài)，但是也不能太大，導致應用浪費外部資源。“后退調優(yōu)”一節(jié)討論了如何決定這些池的最佳大小，但是在本節(jié)的上下文中，牢記它們代表了一個明顯的等待點。

??? 調優(yōu)通訊基礎設施遠遠超出了本文討論的范圍，因為其具體實現因產品不同而存在明顯的區(qū)別，這包括諸如MSMQ、MQSeries、TIBCO等主流產品。但是請記住，如果一個應用與某消息服務器交互，它必須經過合適的調優(yōu)或者它也代表了一個等待點。

??? 最后一個明顯影響JVM性能的等待點是垃圾收集。它不太適用本文中描述的等待點分析過程（檢查一個請求，定位導致該請求等待的技術），但是由于它可以對性能產生顯著的影響，所以把它列在這里。不同的JVM實現和不同的垃圾收集策略決定了垃圾收集如何執(zhí)行，但是在很多情況下，一次主垃圾收集（或者說標記—清除—壓縮垃圾收集）可能導致整個JVM暫停直到垃圾收集完成。一個顯著提高JVM性能的辦法就是優(yōu)化垃圾收集。如果想了解更多垃圾收集的信息，請加入GeekCap討論應用基礎設施調優(yōu)。

已有 0 人發(fā)表留言，猛擊->>這里<<-參與討論


ITeye推薦

• —軟件人才免語言低擔保 赴美帶薪讀研！—