WebLogic性能調優：速度不是一切

WebLogic性能調優：速度不是一切　

追求原始速度的過程，會使可讀性強的代碼變得晦澀難懂（通常是無用的——目前的優化編譯器相當不錯），從而導致以后維護困難；而且在很多情況下，整體方案中的優化性能指標無法吸引人們的興趣。很多人只注重完成一次請求所需的時間——“這次交易僅用了20微秒就從儲蓄帳戶中取出500英鎊，哇！”

　　對于事務型系統來說，系統的吞吐量通常遠遠要比一次請求的絕對速度更吸引人（盡管這么說，執行事務所需的時間還是必須滿足某種限制條件）。吞吐量衡量系統在達到響應時間目標的情況下可以處理的工作量。當然了，系統中更多的客戶端請求事務是產生更多工作的部分原因。此處的另一個有趣的因素是，響應時間和客戶端數量不是獨立的變量——拋給系統工作的客戶端越多，單個事務就越有可能使用更長的時間。因此，（在給定的部署環境下）系統的最大吞吐量支配著多少個客戶端可以以某個預期的速率提交事務，并將多少事務（比如說90%）的響應時間維持在要求的時限內。得出這個結論以后，在嘗試預測生產設置以滿足所需的服務水平并優化服務器資源的使用時，更改各種系統參數（執行線程數、數據庫連接數、機器數等等）會不斷地產生有趣的結果。

　　事實上，對于任何使用應用服務器的人來說，單個事務的個體往返時間對性能沒有太大影響已經不是什么新鮮之談了。很明顯，優化的方式是盡可能地縮短客戶端和該客戶端所作用的后端之間的代碼路徑——而客戶端和后端之間的應用服務器基礎架構中的粘合層顯然不利于縮短代碼路徑。但是，它卻能提高吞吐量，這主要是通過在客戶端中間共享稀有的服務器端資源（數據庫連接、線程等等）而實現的。如果簡單地通過縮短代碼路徑來提高性能，最終只會在客戶端數目和服務器上所使用的資源之間建立一對一的關系；而一旦所有的服務器資源都被使用了，就會產生性能瓶頸，吞吐量也就無法進一步得到提升，除非可以整合更多的資源并共享出來。應用服務器的真正作用是，通過在客戶端之間共享來節約服務器端所使用的資源數（代價是會產生較長的代碼路徑，這暗示著會或多或少地延長事務的往返時間），從而提高系統的最大可能吞吐量。從這方面來說，“我不使用事務，它們會降低速度”的說法是有道理的。

　　到目前為止，我們已經看到，系統要在有限的服務器資源下運行盡可能多的請求。但是沒有說所有這些請求必須得到正確的結果——也就是說，任何獨自執行的請求的結果應當與它與其他許多請求一起執行時所得到的結果一致（或者說，請求應當具有隔離性，當然了，隔離性(isolation)就是ACID中的“I”，而提供ACID屬性的是事務）。因此，使用XA事務的代價是犧牲一點點絕對性能，而益處是得到正確的事務結果。如果您存款的銀行使用XA，那么您就可以高枕無憂了，因為您知道，即使在某些模糊負載條件下從銀行帳戶中提款也不會出錯！

　　這些討論全都發生在數據層——XA完全是關于數據庫事務的。每一個事務會將數據鎖定在數據庫中，直到事務完成；隨后等待方才能看得到結果。當多個請求試圖訪問相同的數據時，事務就會引發瓶頸問題——除了第一個鎖定爭用數據的請求之外，其他請求都被阻塞或拋出，從而嚴重地影響了吞吐量，因為正在做的工作不會導致系統中有一個良好的事務流。

　　然而，數據庫中的數據不是事務系統中唯一共享的資源。我已經討論了應用服務器作為資源共享機制的作用——任一個資源都可能被爭用；因此，如果多個請求同時訪問，則應用服務器本身需要鎖定內存中的數據結構以避免產生問題，而且這里也會產生爭用。當然了，除應用服務器之外的各層也進行資源共享——在一個典型服務器中，為WebLogic配置的60個執行線程很可能至多在幾個CPU中執行——當發生CPU爭用時，那些不走運的線程就必須在隊列中等待，直到某個CPU空閑；內存或者硬盤也是如此。

　　總之，到目前為止我所提到的都是大問題——性能測試的開發、完成所有調優后測試的運行、滿足預期要求的服務器資源分配，這些都隨著不斷變化的應用程序版本和服務器環境版本而反復進行，產生的特定系統必須承受得起不可預知的實際負載。這些不只是難題，也是每一個應用程序生命周期成本的主要部分。

　　聰明的讀者會注意到我的電子郵件地址已經變更；這是因為我已經加入了Azul Systems，該公司有應對上述問題的獨特解決方案。Java是多線程的，因此可以提供包含多個CPU且每個CPU都具有多個內核的系統；這些Java線程實際上就產生了并行化；其次，它提供對同步Java對象的樂觀鎖定的支持，以減少Java軟件層中的爭用；再次，它提供可以在多個應用程序之間共享的內存池?？偠灾?，Azul Appliance提供了一種Java執行引擎，它通過為單個應用程序提供大量的CPU和內存資源，從而試圖緩解傳統虛擬機環境中由于CPU或內存不足而產生的瓶頸，從而降低了系統使用的資源量。

　　該策略還有另外一個優點，即它在一定程度上避免了基于每個應用程序進行調優的需要，這是因為設備提供的資源非常多，以至于可以輕松地在多個應用程序之間共享；而以前，每一個應用程序都需要在自己的服務器上為需求峰值預留一定的空間。這種共享是可以實現的，因為總的來說，需求峰值是平滑的（因為很多不相關的應用程序同時達到需求峰值的情況不大可能發生）；因此，需求可以通過池化的資源得到滿足，從而使您既不用擔心應用程序級的大?。ㄒ约跋嚓P成本），也不用擔心每個應用程序基礎上的硬件過量供應。這預示著一個以低成本采購和管理的設備來運行高性能Java應用程序的新時代來臨了。

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