Sun Java System Application Server 9.1 部署規劃指南

建立效能目標

簡單來說，高效能是指增加流量並縮短回應時間。除了這些基本目標，還可以透過決定下列項目以建立特定的目標：

要部署的應用程式與服務類型為何，以及用戶端要如何存取這些應用程式與服務？
哪些應用程式與服務需要高可用度？
應用程式具有階段作業狀態或無狀態？
系統必須支援的請求容量或流量為何？
系統必須支援多少同步運作的使用者？
可接受的使用者請求平均回應時間為何？
請求之間的平均考慮時間為何？

您可以使用模擬預期應用程式活動的遠端瀏覽器模擬器 (RBE) 工具或網站效能與基準軟體，計算部分度量。一般來說，RBE 與基準產品會產生同步運作的 HTTP 請求，然後報告指定的每分鐘請求數之回應時間。然後，您可以使用這些數據計算伺服器活動。

本章所述的計算結果並非絕對。由於您需要微調 Application Server 與應用程式的效能，因此請將結果當作工作時的參考點。

本節論述以下主題︰

估計流量

廣義來說，流量可用來測量 Application Server 執行的工作量。對於 Application Server 而言，流量可定義為每個伺服器實例每分鐘處理的請求數。高可用性應用程式也會使 HADB 有更高的流量需求，以定期儲存階段作業狀態資料。對於 HADB，流量可定義為每分鐘儲存的階段作業資料量，這是每分鐘 HADB 請求數與每個請求平均階段作業大小的乘積。

如下一節所述，Application Server 流量是由許多因素決定的函數，這些因素包含使用者請求的特性與大小、使用者數目，以及應用程式伺服器實例與後端資料庫的效能。您可以模擬的工作負荷量為基準，估計單一機器上的流量。

高可用性應用程式因為會定期將資料儲存至 HADB，因此會造成額外的經常性耗用時間。額外的經常性耗用時間量取決於資料量、資料量變更頻率及資料儲存頻率。前兩項因素與討論的應用程式相關，最後一個也會受到伺服器設定所影響。

HADB 流量可定義為每分鐘 HADB 請求數乘以每個請求的平均資料量。HADB 流量愈大表示需要愈多的 HADB 節點，以及愈大的存放區。

估計應用程式伺服器實例的負載

請考慮下列因素以估計應用程式伺服器實例的負載：

同步運作使用者人數上限

使用者透過 Web 瀏覽器或 Java 程式等用戶端，與應用程式互動。視使用者動作之不同，用戶端會定期將請求傳送至 Application Server。只要使用者的階段作業尚未到期或終止，該名使用者即會視為目前的使用者。估計同步運作使用者人數時，請納入所有目前的使用者。

下圖描述每分鐘處理的請求數 (流量) 與使用者人數的典型圖形。最初，當使用者人數增加時，流量會相對增加。但是，當同步運作請求數目增加時，伺服器效能會開始飽和，且流量會開始降低。

找出增加同步運作使用者會降低每分鐘可處理的請求數之時間點。此時間點表示達到最佳效能的時候，在此時間點之後流量會開始降低。一般會儘可能地以最佳流量來運作系統。您可能需要增加處理能力，以處理額外的負載並增加流量。

考慮時間

使用者不會無間斷地送出請求。使用者送出請求，伺服器接收並處理請求，然後傳回結果，此時使用者會花些時間才會再送出新的請求。一個請求與下一個請求之間的時間稱為考慮時間。

考慮時間取決於使用者的類型而定。例如，機器對機器的互動 (如 Web 服務的互動) 一般需要比人類使用者的互動更短的考慮時間。您在估計考慮時間時，必須將機器與人類的混合互動列入考量。

判斷平均考慮時間很重要。您可以使用此持續時間計算每分鐘必須完成的請求數，以及系統可支援的同步運作使用者人數。

平均回應時間

回應時間是指 Application Server 將請求結果傳回給使用者所需的時間。回應時間受到網路頻寬、使用者人數、送出的請求數目與類型，以及平均考慮時間等因素的影響。

在本節中，回應時間是指平均回應時間。每種請求類型各有其最短回應時間。但是，評估系統效能時，請根據所有請求的平均回應時間分析。

回應時間愈快，每分鐘處理的請求數愈多。但是，如下圖所述，當系統上的使用者人數增加時，回應時間也會開始增加，即使每分鐘請求數減少亦然：

抱歉：本版手冊尚未提供此圖。

類似此圖的系統效能圖會指出在過了特定時間點後，每分鐘請求數會與回應時間呈反比。每分鐘請求數減少幅度越大，回應時間的增加幅度就越大 (以虛線箭頭表示)。

在圖中，尖峰負載點是每分鐘請求數開始減少的時間點。在此時間點之前，回應時間的計算不一定正確，因為未在公式中使用尖峰數目。在此時間點之後，由於每分鐘請求數與回應時間呈反比關係，所以管理員可以透過使用者人數上限及最大每分鐘請求數，更精準地計算回應時間。

使用下列公式判斷 T_回應，亦即尖峰負載時的回應時間 (以秒為單位)：

T_回應 = n/r - T_考慮

其中

n 是同步運作使用者人數
r 是伺服器每秒鐘接收的請求數
T_考慮是平均考慮時間 (以秒為單位)

若要取得正確的回應時間結果，請一律將考慮時間列入方程式。

範例 2–1 回應時間的計算

假設存在下列條件：

系統在尖峰負載時，可支援的同步運作使用者人數上限 n 為 5,000 人。
系統在尖峰負載時，可處理的最大請求數 r 為每秒 1,000 個。

平均考慮時間 T_考慮為每個請求三秒。

回應時間的計算如下：

T_回應 = n/r - T_考慮 = (5000/ 1000) - 3 秒= 5 - 3 秒

因此，回應時間為兩秒。

計算系統的回應時間之後 (特別是在尖峰負載時)，請與應用程式可接受的回應時間做比較。回應時間及流量是決定 Application Server 效能的主要因素。

每分鐘請求數

若隨時知道同步運作使用者人數、這些使用者請求的回應時間，以及使用者平均考慮時間，即可計算每分鐘的請求數。一般會從估計系統上的同步運作使用者人數開始。

例如，執行網站效能軟體之後，管理員得知同時在網路銀行網站送出請求的使用者平均人數為 3,000 人。此人數取決於已登記成為網路銀行會員的使用者人數、使用者的銀行交易行為、使用者選擇送出請求的日期時間...等等。

因此，瞭解此資訊可讓您使用本節所述的每分鐘請求數公式，計算系統根據此使用者人數每分鐘可處理的請求數。由於每分鐘請求數與回應時間在尖峰負載時會形成反比，因此請決定是要接受較少的每分鐘請求數以換取較佳的回應時間，還是要接受較慢的回應時間以換取每分鐘更多的請求數。

實驗不同的可接受每分鐘請求數與回應時間臨界值，作為微調系統效能的起點。接著決定需要調整的系統區域。

求解上一節方程式中的 r 得出：

r = n/(T_回應 + T_考慮)

範例 2–2 每秒請求數的計算

假設下列值：

n = 2,800 名同步運作使用者
T_回應 = 1 (每個請求平均回應時間為一秒)
T_考慮 = 3 (平均考慮時間為三秒)

每秒請求數的計算如下：

r = 2800 / (1+3) = 700

因此，每秒請求數為 700，而每分鐘請求數為 42000。

估計 HADB 的負載

若要計算 HADB 的負載，請考慮下列因素：

如需有關配置階段作業持續性的指示，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 9 章「配置高可用性階段作業持續性和容錯移轉」。

HTTP 階段作業持續性頻率

HADB 接收的每分鐘請求數取決於 持續性頻率。持續性頻率會決定 Application Server 將 HTTP 階段作業資料儲存至 HADB 的頻率。

持續性頻率選項包括：

Web 方法 (預設值)：伺服器會在每次 HTTP 回應時儲存階段作業資料。此選項可保證儲存的階段作業資訊是最新的，但其會造成 HADB 的高流量。
以時間為基礎：階段作業會依指定時間間隔儲存。此選項會降低 HADB 的流量，但不保證階段作業資訊是最新的。

下表是持續性頻率選項的優缺點摘要。

表 2–1 持續性頻率選項的比較


持續性頻率選項	優點	缺點
Web 方法	保證可提供最新的階段作業資訊。	可能增加回應時間並降低流量。
以時間為基礎	改善回應時間，並有可能增加流量。	較無法保證可在應用程式伺服器實例故障之後仍能提供最新的階段作業資訊。

HTTP 階段作業大小與範圍

每個請求的階段作業大小取決於階段作業中所儲存的階段作業資訊量。

提示 –

若要改善整體效能，請儘可能降低階段作業中的資訊量。

可透過 持續性範圍設定，微調每個請求的階段作業大小。請從 HTTP 階段作業持續性範圍的下列選項中選擇：

session：每次伺服器將階段作業資訊儲存至 HADB 時，便會序列化並儲存整個階段作業物件。
modified-session：伺服器僅會在階段作業已修改時儲存階段作業。伺服器可截取對 Bean 的 setAttribute() 方法之呼叫，以偵測有無修改。此選項不會偵側對內部物件的直接修改，因此在這類情況下，必須編寫 SFSB 程式碼以明確呼叫 setAttribute()。
modified-attribute：伺服器僅會儲存自上次儲存階段作業以來，已修改 (已插入、已更新或已刪除) 的屬性。這與 modified-session 有相同的缺點，但是若套用適當，則可大幅降低 HADB 的寫入流量需求。

若要使用此選項，應用程式必須：

在每次修改階段作業狀態時，呼叫 setAttribute() 或 removeAttribute()。
確定各屬性之間沒有交叉參照。
在多個屬性之間分布階段作業狀態，或者至少在唯讀屬性和可修改屬性之間分布階段作業狀態。

下表是持續性範圍選項的優缺點摘要。

表 2–2 持續性範圍選項的比較


持續性範圍選項	優點	缺點
modified-session	當請求不修改階段作業狀態時，提供較優良之請求回應時間。	執行 Web 方法期間 (一般是 `doGet()` 或 `doPost()`)，應用程式必須呼叫階段作業方法： `setAttribute()`，若已變更屬性。 `removeAttribute()`，若已移除屬性。
session	應用程式沒有限制。	與 `modified-session` 和 `modified-attribute` 選項相較下，可能使流量及回應時間更差。
modified-attribute	在請求的階段作業狀態修改比例很低的情況下，改善請求的流量與回應時間。	當指定請求的階段作業狀態修改比例接近 60% 時，流量會降低且回應時間會變慢。在這類情況下的效能是所有選項中最差的，因為將屬性分割成個別的記錄會造成額外的經常性耗用時間。

有狀態的階段作業 Bean 檢查點檢查

對於 SFSB 階段作業持續性，HADB 的負載與下列項目相關：

啟用檢查點檢查的 SFSB 數目。
已選取哪些 SFSB 方法進行檢查點檢查，以及這些方法使用的頻率。
階段作業物件的大小。
哪些方法會有所異動。

檢查點檢查一般會在完成 SFSB 的任何作業事件之後發生，即使作業事件回復亦然。

如需更佳的效能，請指定一小組方法進行檢查點檢查。進行檢查點檢查的資料大小與檢查點檢查的頻率，會決定指定用戶端互動之回應時間的額外經常性耗用時間。