門戶中的資源掛起線程應急解決方案

業務任務

您的門戶出現用戶請求在資源中掛起情況的頻率是多高？我希望這種情況不經常發生。然而，如果出現了這種情況，而且資源不斷掛起用戶請求，則門戶會面臨耗盡所有已配置的并發用戶請求并最終崩潰的致命風險。這將是一場災難。我碰到過幾次這樣的情況，并決定保護我的門戶不再受類似情況的影響。

我們需要讓門戶包含幾個具有登錄控件（通過用于每個Portlet的備份文件提供）的Portlet。對于每個請求，創建一個備份文件，備份文件在用戶請求方面是線程安全的。在登錄控件中，備份文件的init()方法（或preRender()方法）調用獨立的安全服務（資源）API以獲得資源訪問授權。對于業務處理，Portlet也通過其他API調用將用戶請求委托到業務層。一切都運行正常，直到一個對資源的調用未返回到Portlet，即，由于某種原因，它在某處掛起了。以下是一個具體示例。

我們假定WebLogic Portal使用EJB作為業務層和/或安全服務中的資源。此EJB操作其他資源，并通過使用JMS發送消息的方式報告處理狀態。此EJB與其他應用程序一起部署在集群中。門戶部署在另一個物理機器上。如果共同部署的一個應用程序引發了內存錯誤，則整個集群（包括EJB）都會掛起，即它不返回請求也不拋出異常。事實上，討論如此顯著的失效是沒有必要的：從門戶的角度來說，“掛起”模式僅是門戶的動態并發生命周期中的一種返回得過慢、延遲過久以至于不能接受的響應。例如，延遲可能由于服務器過載或數據庫出現問題引起，但這是不相干的——備份文件中的線程運行時間超出了正常門戶工作的允許范圍，達到了門戶中的“最大并發用戶數”。此門戶完全停止接受用戶請求——這就成了問題。

解決方案設計

我首先想到的是，在Portlet用于訪問其資源的RMI客戶端（即EJB客戶端）上設置超時（遠程－客戶端－超時）。然而，關于使用RMI超時的WebLogic指導原則列出了關于此類超時的幾條限制，其中包括“在調用中不涉及JMS資源。”這就是說，不能對EJB資源使用超時。我提及這種情況只是為了說明存在門戶可能未被保護以不受掛起的資源線程影響的情況。即使沒有關于超時的限制，如果請求掛起的速度快于超時釋放相關線程的速度，問題就依然存在。

我想介紹一種針對此問題的可能解決方案。此解決方案在下面的條件下有效：門戶具有一些獨立于可能會掛起的資源的內容或功能。就是說，門戶可以運行部分功能。

此解決方案包括3個組件：監控、決策規則和規則實施方法。此解決方案的原理很簡單：門戶監控運行中的資源調用，從而監控被調用的資源線程，對運行過久的資源線程的數量進行計數（riskCounterValue），然后應用決策規則，如“如果riskCounterValue達到或超出預定義的閾值（riskThreshold），則所有傳入的對此資源的調用均被拒絕，直到riskCounterValue小于riskThreshold。”使用此規則可以限制可能“掛起”的資源線程數量，而且可能使用簡化功能處理用戶請求。例如，如果門戶包含4個Portlet，用于一個Portlet的某些資源線程被認為“存在掛起的風險”，則門戶可以跳過存在風險的Portlet而僅對用戶顯示3個Portlet。

規則實施方法的實現非常重要。如果此規則在每個調用的范圍內執行，我們可以預見性能會降低，但是可以輕松地控制可能“掛起”的資源線程。如果此規則在調用以外執行，我們可以保持性能，但是對此類控制的調整是需要技巧的。我們將詳細討論后一種情況。圖1的圖描述了這種情況。

如圖所示，在第一步中，門戶初始化一個Helper對象，而此Helper對象則初始化一個CallRegistry對象。后者可作為java.util.HashMap實現，并用于注冊所有對資源API的調用。然后Helper啟動一個watchdog線程。例如，如果使用Struts，則此線程就在模型中啟動。watchdog線程定期檢查CallRegistry中的記錄，對運行時間過長的調用數量進行計數，并將其設置為Helper中的riskCounterValue變量。

假定我們大概知道API調用的正常執行時間。該值（最長持續時間）可以用于所有的API，或者每個API可以具有其單獨的執行時間。因此，當調用一個API方法時，我們可以計算此API在正常情況下預期完成的時間，例如：

java.lang.System.currentTimeMillis()
long apiExecutionTime = ...;// property
long timeToComplete =
      java.lang.System.currentTimeMillis() + apiExecutionTim 

當調用Helper的方法時，它將一條新記錄添加進CallRegistry。此記錄包括一個惟一的調用ID（用作java.util.HashMap中的鍵）和用于API的預期完成時間（timeToComplete）（用作java.util.HashMap中的值）。如果此方法成功完成，它會從CallRegistry移除其記錄。

讓我們來看一下用戶請求是如何處理的。接到用戶請求后，Portlet的備份文件將其委托給Helper API方法（后者調用資源API）。首先，此Helper API方法檢查其是否可以執行。如果接到請求的時候尚未達到riskThreshold，則此Helper API方法繼續運行。否則，它會拋出一個異常，門戶會繼續下一項功能或下一個API調用。

僅在運行時間過長的資源線程數量（riskCounterValue）小于riskThreshold的情況下才可以賦予執行的權限。通過配置屬性設置riskThreshold。例如，如果將并發用戶請求最大值配置為25，則riskThreshold可以設置為10。這就是說，門戶處理并發用戶請求的能力僅存在一半風險，它在資源線程開始掛起的情況下仍然可以運行。

請注意我們不對運行時間過長的API調用進行任何操作。它們中的一些最終可以成功完成，Helper API方法會將其記錄從CallRegistry移除，即下一次計數可能會低于riskThreshold，下一次針對資源的用戶請求可能不會被拒絕（通過拋出異常的方式）。

門戶無法知道網絡中是否存在意外延遲或者資源線程是否確實掛起。因此，推薦在幾個順序控制周期中達到或超出riskThreshold時給操作團隊發送一個通知（例如，通過電子郵件）。收到的通知允許操作團隊迅速分析日志，及時找到并解決運行時間過長的調用的原因。

分析和調整

對“掛起”的資源線程的控制具有很大的動態性，要對其進行調整并不是一件簡單的事。其效果是基于對以下3個參數的權衡：

• 用戶請求之間的平均時間（TUR）與watchdog線程控制周期（風險控制周期）之間的時間（TRC）的比率：R = TUR / TRC
• 用于特定資源的風險閥值（riskThreshold）
• 資源API調用的預期執行時間

對控件的研究和測試得出的結論是，參數調整取決于特定的門戶實現，但具有共同的趨勢。圖2中的圖表展示了用于調整的準則。在測試中，比率被設為R = 95%，TUR為95［ms］，TRC被設為100［ms］。通常，可靠的比率是90%或更高。

此圖表顯示“掛起”的API調用數（在控件中計數）是如何取決于調用執行時間的。圖表中的點代表風險控制周期之間掛起的用戶請求的最大數量，即在針對給定調用執行時間而進行的一系列測試中的riskCounterValue最大值。請記住，在實施決策規則時，一些用戶請求被拒絕，而“掛起”的資源線程數量不會增加。

圖2中的水平紅線標記門戶中所允許的最大并發用戶數量。控件的目的是將最大riskCounterValue嚴格保持在紅線以下。圖表中的點越接近紅線，就越可能達到或超出riskThreshold。

我們可以看到，控制的行為不明顯。對于某些調用執行時間值（從3250ms到1500ms），控件生成用戶請求，“掛起”的資源線程數量接近并超出門戶允許的并發用戶最大值。在此間隔期間，控制在給定條件下是無效的。同時，控制在從100ms到1000ms和從3500ms到4000ms的2個間隔中是有效的：具有特定riskThreshold的決策規則可靠地保護門戶不受“掛起”的API調用的影響，并保留足夠的并發請求線程以服務其他用戶請求。

此圖表還顯示較小的riskThreshold可提供較好的保護。但是，如果將一個資源的riskThreshold設置得過低，資源可能僅僅由于網絡延遲的輕微波動就在大多數用戶會話中不可用。這是另一個主題了：平衡和調整。

結束語

這套關于“掛起”的資源調用的運行時控制的推薦解決方案允許門戶隔離有問題的資源，并使用余下的資源繼續運行，從而最大程度地減小對性能的影響。此解決方案的效果取決于以下幾個調整參數：請求頻率和風險控制周期頻率的比率、風險閥值的值和預期的調用執行時間。

這種情況下的調整不是一件容易的事——它需要密集的測試。此外，本文中給出的數字是特定于我的測試門戶的，即使您發現了相關性，在您的門戶上進行的測試中使用的應該是其他值。另一方面，如果某種程度的性能降低是可以接受的，則推薦在每個API調用的范圍內執行風險控制周期，以顯著簡化解決方案參數的調整。

參考資料

• WebLogic RMI特性和指導原則：關于使用RMI超時的指導原則http://e-docs.bea.com/wls/docs81/rmi/rmi_api.html
• Nyberg, G.、Patrick, R.、Bauerschmidt, P.、McDaniel, J.以及Mukherjee, R.所著的“Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications”，Wiley E-Book，2004年3月出版。ISBN: 0-471-48090-8。

原文出處: http://wldj.sys-con.com/read/185309.htm

posted on 2006-06-11 14:54 【Xine】中文站 閱讀(516) 評論(0)  編輯  收藏 所屬分類: Bea Weblogic