可擴展性是系統中的一個非常重要的非功能性需求。但系統中可能有多個瓶頸會阻礙系統的擴展性。在這篇文章中，我們嘗試分析軟件基礎結構成為瓶頸的案例，而不考慮硬件資源上的限制（如CPU、磁盤空間、網絡速度等）。下面我們將探討一下這個問題。

下面是一些整篇文章中用到的一些術語：
·吞吐量：系統支持的每秒能夠處理的事務個數。
·服務請求：每個事務中特定硬件的使用率，等于硬件使用率除以吞吐量。
·硬件資源：指處理器、內存、磁盤和網絡。
·軟件資源：指WEB線程、執行線程、BEAN池及數據庫連接池等。
·預計時間：用戶預計兩次并發提交請求之間的時間。
·短時間法則：一個驗證測試及確信測試環境不是瓶頸的法則。
·響應時間：用戶等待他提交的請求返回響應的時間。

理論基礎

任何J2EE應用通常都有下面幾個層次，如圖1：
1、硬件基礎結構資源（處理器、內存、磁盤和網絡）
2、軟件基礎結構資源（JVM,WEB服務器、應用服務器、數據庫服務器）
3、軟件應用（J2EE應用）



Figure 1. Snapshot of a J2EE system

這兒有兩個可能性導致瓶頸：硬件成為主要瓶頸或者軟件成為主要瓶頸。在第一種情況，硬件資源不足夠而軟件資源很充分，如圖2。隨著負載的增加，硬件資源成為瓶頸，而軟件可以繼續擴展。減輕這個瓶頸的方案通常是擴大或者增加硬件。




Figure 2. The hardware pipe becomes a bottleneck


在第二種情況，硬件資源是足夠的而軟件資源相對有限。隨著負載的增加，軟件資源成為瓶頸，如圖3。減輕這種瓶頸的方案通常是使用軟件群集或優化軟件。




Figure 3. Software pipe becomes a bottleneck

應用服務器如何工作？

來考慮一下應用服務器的內部機制。應用服務器的基本功能包括事務管理、數據持久、對象池、SOCKET處理和請求處理。這些功能的流程如圖4。有各種組件來處理這些功能。這些組件需要同步應用服務器中的線程來維護數據的一致性并操作數據。雖然這種同步對應用服務器的功能正確性是必須而且有用的，但是也成為高負載的限制，即使有足夠的硬件資源。




Figure 4. Internals of an application server

實驗

為了理解瓶頸的狀況，我們在基于Windows/Intel平臺用流行的J2EE應用服務器來測試一下JAVA PETSTORE應用。一些測試用例如PetStore應用的瀏覽和購買周期來測試擴展性。我們確信整個測試環境（包括操作系統、JVM、應用服務器和應用自身）已經盡可能優化了，而且J2EE應用沒有任何瓶頸或同步問題。我們使用了多用戶負載測試并觀察了響應時間、吞吐量、資源利用率等指標。

環境如下：
1、        J2EE PetStore應用
2、        J2EE應用服務器
3、        Sun JVM 1.3
4、        Windows 2000高級服務器
5、        Intel Dell PowerEdge 8450 (8Intel至強800MHz處理器, 4GB RAM)
6、        100Mbps Cisco dedicated network
7、        負載測試工具WebLoad








在這個測試中我們看到即使有足夠的硬件資源，應用服務器的實例個數限制了擴展的能力。在這里軟件資源（如執行線程、BEAN池大小、數據庫池和其他應用服務器參數）優化后即使這些資源不足也不會影響系統的擴展。下面我們來研究一下減輕這種問題的方案。
注：Sun J2EE PetStore可以被更多地優化來改善性能和可擴展性。


解決方案

同一機器上的群集

當吞吐量滿載了應用服務器的一個實例時，需要增加一個實例來減輕這種問題。這個方案如圖5。




Figure 5. Instance clusters on the same hardware box

當前機器的CPU使用率只有40%因而有足夠空間來增加一個實例。我們可以發現在增加了實例后，吞吐量也增加了50%，如表2





在不同機器的群集
當吞吐量滿載了應用服務器的一個實例時，機器的CPU使用率只有40%。因為8CPU的機器未完全利用，所以我們測試一下更低配置的機器。現在我們使用兩個4CPU的機器，如圖6。




Figure 6. Instance clusters on different hardware boxes


我們發現4CPU機器的CPU使用率已達到80%，再增加實例也沒有什么用處了。因此我們又增加一臺4CPU的機器來運行應用的實例。在增加機器后，吞吐量幾乎翻了一倍。在這里我們確信數據庫服務器不會成為瓶頸。

注：在上面的兩臺機器的測試中，負載平衡是通過一種不增加應用服務器實例功能負載的方式來處理的。但是在實際的生產環境中很難做到。

因為我們觀察到8CPU的機器被沒有被完全利用，所以我們使用4CPU的機器重新測試了一遍。測試的結果可以在下表中看到，分別對應配置1和2。4CPU的配置幾乎被完全利用了，這意味著使用4CPU的配置比8CPU的配置更實際，因為前者花費更少。





小結

這些實驗指出了軟件基礎結構如應用服務器實例可能成為瓶頸，并給出了一些解決方案來減輕這種問題（包括在相同或不同機器上的群集）。這個問題需要在J2EE應用的負載計劃或大小確定時優先考慮，因為這直接影響到應用的擴展性。這種想法很重要，下面我通過一個情景對話來表達。

項目經理：你的意思是應用服務器（代表軟件基礎結構）會成為系統的瓶頸。
性能架構師：是的
項目經理：那為什么這種情況不是經常發生。
性能架構師：是的，因為有時候瓶頸首先發生在硬件或應用本身。這時候應用服務器還沒有使用到所有的擴展性。
項目經理：這是事實。那么解決這種瓶頸的方法就是使用群集。如果有足夠的硬件資源就在同一臺機器上跑群集否則在多臺機器中配置。
性能架構師：是的。這也是在這篇文章中所得到的。