專利名稱：用于具有自調(diào)整線程模型的應(yīng)用服務(wù)器的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及應(yīng)用服務(wù)器和消息傳遞系統(tǒng)，特別涉及一種用于具有自調(diào)整線程模型的應(yīng)用服務(wù)器的系統(tǒng)和方法。
背景技術(shù)：
在可能存在幾百或幾千個并發(fā)用戶(客戶端)的典型應(yīng)用服務(wù)器或網(wǎng)絡(luò)服務(wù)器環(huán)境中，這些客戶端中的每個可以將請求發(fā)送到服務(wù)器。圖1示出了這種環(huán)境的示例?，F(xiàn)代服務(wù)器100可以具有多個處理器以及服務(wù)于這些處理器的多個線程102。線程從客戶端104、106、108獲得請求110、112、114，并且以類似于隊(duì)列的方式將它們施加到處理器。實(shí)際所使用的線程數(shù)目對服務(wù)器性能及其處理大量用戶的能力具有巨大影響。然而，算出線程的最優(yōu)數(shù)目是復(fù)雜的處理。
一種對此問題的解決方案是增加甚至更多的線程，從而線程數(shù)大大地超過處理器數(shù)。這確保了幾乎立即將請求供應(yīng)到線程中，但是不確保這些請求迅速地被處理器處理。一種較新的替代方案是創(chuàng)建線程池，其中運(yùn)行靈活數(shù)目的線程。然后，可以由管理員微調(diào)實(shí)際的線程數(shù)目，以便為具體的運(yùn)行時間環(huán)境提供最佳性能。然而，該處理嚴(yán)重地取決于管理員的技術(shù)，因?yàn)樗诤艽蟪潭壬鲜黔h(huán)境相關(guān)的并且是靜態(tài)的，并且大多數(shù)僅僅用于測試平臺和營銷的目的。在現(xiàn)實(shí)生活的情形中，環(huán)境如此多變以致于該靜態(tài)方案無法令人滿意。
因此，需要一種用于允許服務(wù)器基于工作負(fù)載的目標(biāo)預(yù)測而自動地確定和實(shí)現(xiàn)最優(yōu)數(shù)目的并發(fā)線程的裝置。由于應(yīng)用服務(wù)器所處位置(在操作系統(tǒng)之上)的限制，因此不能將該線程控制嵌入到操作系統(tǒng)內(nèi)，而是必須存在于更高級別。因此，應(yīng)當(dāng)存在一種用于控制在應(yīng)用服務(wù)器中的線程的數(shù)目和供應(yīng)它們的隊(duì)列的裝置。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的實(shí)施例，提供了一種用于具有自調(diào)整線程模型的應(yīng)用服務(wù)器的系統(tǒng)和方法。根據(jù)實(shí)施例，使用服務(wù)器隊(duì)列作為優(yōu)先級方案，其中包括多個與所接收的請求相關(guān)聯(lián)的條目，并且其允許條目表達(dá)比僅僅線程數(shù)目更加自然和更接近于商業(yè)用戶的優(yōu)先級。仍然保留靈活性，以在可能希望其的情況下(例如，如果存在除非使得特定數(shù)目的線程可用、否則將會死鎖的巳知調(diào)用序列)以原始數(shù)目表達(dá)線程，或者基于全系統(tǒng)范圍或工作負(fù)載而表達(dá)對要使得可用的線程數(shù)目的約束。
根據(jù)實(shí)施例，可以將優(yōu)先級指定為“份額”，其是反映將接收請求的實(shí)體之間的相稱優(yōu)先級的抽象概念。由于總數(shù)是任意的，并且可能存在大于100的份額，因此盡管份額與百分比線程使用類似，但它們并不相同。份額確定分配給每個實(shí)體的線程使用(按照線程數(shù)目)。然后，系統(tǒng)(或運(yùn)行在其上的算法)確保在長期時間內(nèi)，將根據(jù)這些份額分配線程的使用(按照線程時間)。例如使用已經(jīng)被分配的時間或線程分鐘數(shù)的兩倍的任何實(shí)體將受到懲罰，以使相對使用比例回到平衡。
根據(jù)實(shí)施例，在運(yùn)行時間期間，該算法還可以用來調(diào)整線程池的大小，然后在該池內(nèi)分配線程。
根據(jù)實(shí)施例，維護(hù)優(yōu)先級隊(duì)列。每個請求實(shí)體，例如客戶端，可以發(fā)布進(jìn)入隊(duì)列、并且根據(jù)相對份額而被分隔開的請求。從而，例如，與用盡了其分配或者具有基于較低時間的分配或份額的另一實(shí)體相比，如果該實(shí)體沒有超過其分配，則可以將其請求放置在隊(duì)列中的相對高處，并且將立即開始獲得線程。
根據(jù)實(shí)施例，對于最大線程約束，系統(tǒng)可以維護(hù)獨(dú)立的隊(duì)列，用于將請求保存在優(yōu)先級隊(duì)列中、以及最大線程約束隊(duì)列中。當(dāng)清除了最大線程約束隊(duì)列時，將允許執(zhí)行優(yōu)先級隊(duì)列中的任何類似項(xiàng)目(即，用于相同約束的某項(xiàng)目)。
根據(jù)實(shí)施例，線程池的大小調(diào)整可以縮減到遞增或遞減一個現(xiàn)有池。這是基于周期性地，例如每一秒或兩秒執(zhí)行的。
自調(diào)整線程模型的總體結(jié)果是服務(wù)器的盒外(out-of-the box)性能的大幅度提高。然后，還可以為了適應(yīng)特定需要而定制線程特征。該特性還允許服務(wù)器客戶在設(shè)置其系統(tǒng)時具有更大的靈活性，并且向他們提供方法來針對具體的商業(yè)邏輯或客戶需求集等來區(qū)分其線程模型的優(yōu)先級。


圖1示出了多個客戶端使用線程訪問服務(wù)器的環(huán)境的圖解。
圖2示出了根據(jù)本發(fā)明實(shí)施例的、多個客戶端使用線程和優(yōu)先級隊(duì)列來訪問服務(wù)器的環(huán)境的圖解。
圖3示出了根據(jù)本發(fā)明實(shí)施例的用于使用線程訪問服務(wù)器的處理的流程圖。
具體實(shí)施例方式
目前，應(yīng)用服務(wù)器客戶定義新的線程池并配置其大小，以避免死鎖并提供不同的服務(wù)。這是十分困難的處理。有才能的軟件管理團(tuán)隊(duì)可能花費(fèi)幾天來仔細(xì)考慮用于最優(yōu)性能的配置。
根據(jù)本發(fā)明的實(shí)施例，自調(diào)整服務(wù)器動態(tài)地調(diào)整線程數(shù)，以避免死鎖并且實(shí)現(xiàn)受到并發(fā)約束的最優(yōu)吞吐量。它還滿足用于不同服務(wù)的目標(biāo)。這些目標(biāo)被表述為響應(yīng)時間目標(biāo)、份額和優(yōu)先級。
根據(jù)實(shí)施例，本系統(tǒng)解決與工作負(fù)載管理、執(zhí)行隊(duì)列清除、線程計(jì)數(shù)調(diào)整和過載保護(hù)相關(guān)的要求?？梢詫⒎?wù)器中的多個執(zhí)行隊(duì)列簡化成單個基于優(yōu)先級的隊(duì)列。本系統(tǒng)實(shí)現(xiàn)基于優(yōu)先級的工作調(diào)度方案，其中在隊(duì)列中，高優(yōu)先級工作花費(fèi)較少的時間。調(diào)度考慮了資源約束。主要的焦點(diǎn)是使調(diào)度模型可伸縮，并且使管理員能夠指定工作負(fù)載管理規(guī)則。
根據(jù)本發(fā)明的實(shí)施例，提供了一種用于具有自調(diào)整線程模型的應(yīng)用服務(wù)器的系統(tǒng)和方法。根據(jù)實(shí)施例，使用服務(wù)器隊(duì)列作為優(yōu)先級方案，其中包括多個與所接收的請求相關(guān)聯(lián)的條目，并且其允許這些條目表達(dá)比僅僅線程數(shù)目更加自然和更接近于商業(yè)用戶的優(yōu)先級。仍然保留這樣的靈活性，以在可能希望其的情況下(例如，如果存在除非使得特定數(shù)目的線程可用否則將會死鎖的已知調(diào)用序列)以原始數(shù)目表達(dá)線程，或者基于全系統(tǒng)范圍或工作負(fù)載而表達(dá)對要使得可用的線程數(shù)目的約束。
根據(jù)實(shí)施例，可以將優(yōu)先級指定為“份額”，反映將接收請求的實(shí)體之間的相稱的優(yōu)先級的抽象概念。由于總數(shù)是任意的，并且可能存在多于100個份額，因此盡管份額與百分比線程使用類似，但并不相同。份額確定分配給每個實(shí)體的線程使用(按照線程數(shù)目)。然后，系統(tǒng)(或運(yùn)行在其上的算法)確保在長期時間內(nèi)，將根據(jù)這些份額分配線程的使用(按照線程時間)。例如，使用了已經(jīng)被分配的時間或線程分鐘數(shù)的兩倍的任何實(shí)體將受到懲罰，以使相對使用比例回到平衡。
根據(jù)實(shí)施例，在運(yùn)行時間期間，該算法還可以用來調(diào)整線程池的大小，然后在該池內(nèi)分配線程。
根據(jù)實(shí)施例，維護(hù)優(yōu)先級隊(duì)列。每個請求實(shí)體例如客戶端，可以發(fā)布請求，該請求進(jìn)入隊(duì)列，并且根據(jù)相對份額而被分隔開。從而，例如，與用盡了其分配或者具有較低的基于時間的分配或份額的另一實(shí)體相比，如果實(shí)體沒有超過其分配，則可以將其請求放置在隊(duì)列中的相對高處，并且將立即開始獲得線程。
根據(jù)實(shí)施例，對于最大線程約束，系統(tǒng)可以維護(hù)獨(dú)立的隊(duì)列，用于將請求保存在優(yōu)先級隊(duì)列以及最大線程約束隊(duì)列中。當(dāng)清除了最大線程約束隊(duì)列時，將允許執(zhí)行優(yōu)先級隊(duì)列中的任何類似項(xiàng)目(即，用于相同約束的某項(xiàng)目)。
根據(jù)實(shí)施例，線程池的大小調(diào)整可以縮減(distill down)為遞增或遞減一個現(xiàn)有池。這是基于周期性地，例如每一秒或兩秒執(zhí)行的。
自調(diào)整線程模型的總體結(jié)果是服務(wù)器的盒外(out-of-the box)性能的大幅度提高。然后，還可以為了適應(yīng)特定需要而定制線程特征。該特性還允許服務(wù)器客戶在設(shè)置其系統(tǒng)時具有更大的靈活性，并且向他們提供方法來針對具體的商業(yè)邏輯或客戶需求集等區(qū)分其線程模型的優(yōu)先級。
圖2示出了根據(jù)本發(fā)明實(shí)施例的、多個客戶端使用線程和優(yōu)先級隊(duì)列來訪問服務(wù)器的環(huán)境的圖解。如圖2所示，服務(wù)器120可以具有多個處理器以及服務(wù)于這些處理器的多個線程122。優(yōu)先級隊(duì)列124從客戶端104、106、108獲得請求110、112、114，并且在將這些條目126傳遞到線程之前，將其排入隊(duì)列，其中根據(jù)任何預(yù)先配置的份額值或約束來區(qū)分其優(yōu)先級，然后，線程將它們施加到處理器。
圖3示出了根據(jù)本發(fā)明實(shí)施例的用于使用線程訪問服務(wù)器的處理的流程圖。如圖3所示，在步驟130中，將服務(wù)器配置成根據(jù)份額值在實(shí)體之間共享線程資源。這可以通過管理員以數(shù)值方式輸入份額值的控制臺應(yīng)用程序或通過某種其它類型的設(shè)備。在步驟132中，服務(wù)器從客戶端接收請求。在步驟134中，根據(jù)份額值并且基于每個實(shí)體已經(jīng)使用了多少線程時間，將請求排入優(yōu)先級隊(duì)列。在步驟136中，從優(yōu)先級隊(duì)列獲得請求，并且將其提供給線程，以便由處理器處理。
實(shí)現(xiàn)細(xì)節(jié)性能工程師和應(yīng)用管理員是這些特性的主要用戶。管理員規(guī)定應(yīng)用的調(diào)度目標(biāo)，如公平份額和響應(yīng)時間目標(biāo)。如在本章節(jié)的上下文內(nèi)使用的那樣，使用下面的定義受約束工作集-可以基于工作所共享的資源對它們分組。該工作集中的所有工作的性能受到共享資源的容量的約束。
入口點(diǎn)-例子包括RMI方法描述符、HTTP URI、MDB以及JCA 1.5工作管理器實(shí)例。
公平份額-使用線程的權(quán)利。當(dāng)服務(wù)類競爭線程時，將與其各自的份額成比例地向它們分配線程。該比例僅僅被實(shí)現(xiàn)為服務(wù)類競爭的足夠長時間段上的平均值。如果沒有其它服務(wù)類處于活動狀態(tài)，則可以將全部線程分配給該服務(wù)類。
自調(diào)整-服務(wù)器自動設(shè)置低級內(nèi)核參數(shù)的能力。管理員可以定義他們了解的應(yīng)用要求，例如響應(yīng)時間目標(biāo)，并且服務(wù)器將相應(yīng)地調(diào)整其低級參數(shù)。
響應(yīng)時間目標(biāo)-在請求到達(dá)服務(wù)器中的入口點(diǎn)和發(fā)出響應(yīng)之間可以經(jīng)過的最大毫秒數(shù)的目標(biāo)。
服務(wù)類-服務(wù)類對服務(wù)器中的工作進(jìn)行分組。針對服務(wù)類而非各個請求來表達(dá)和跟蹤目標(biāo)。系統(tǒng)在將請求排入隊(duì)列之前，應(yīng)該能夠確定其服務(wù)類。通過根據(jù)入口點(diǎn)、J2EE模塊、事務(wù)名稱、當(dāng)前用戶、或某指定的工作區(qū)域字段來分組，出現(xiàn)一些有用的服務(wù)類。
調(diào)度策略-基于請求的服務(wù)類和來自競爭服務(wù)類的請求，確定請求的等待時長。
工作負(fù)載管理該特性描述了服務(wù)器如何使用服務(wù)類、約束和在服務(wù)器中觀察到的負(fù)載狀態(tài)來調(diào)度工作。對于在優(yōu)先級隊(duì)列中排隊(duì)的各種工作類，服務(wù)器準(zhǔn)許不同的調(diào)度策略。通過用所提交的工作指定服務(wù)類，這是可能的。該特性使得即使當(dāng)高優(yōu)先級工作更晚到達(dá)時，系統(tǒng)也在較不重要的工作之前調(diào)度高優(yōu)先級工作。在競爭期間，服務(wù)于給定服務(wù)類的線程數(shù)取決于它的規(guī)定目標(biāo)。約束定義了在死鎖和過載狀態(tài)期間內(nèi)核應(yīng)該如何處理工作。
自動線程計(jì)數(shù)調(diào)整服務(wù)器自動地調(diào)整其線程計(jì)數(shù)，以便爭取最大吞吐量，并且實(shí)現(xiàn)最小并發(fā)保證。不再需要諸如threadsIncrease(線程增加)或threadsMaximum(線程最大值)的參數(shù)。
減少在啟動時創(chuàng)建的執(zhí)行隊(duì)列在傳統(tǒng)的實(shí)現(xiàn)中，子系統(tǒng)為了諸如防止死鎖、最小線程保證等的各種原因而創(chuàng)建其自己的執(zhí)行隊(duì)列。自調(diào)整避免了創(chuàng)建多個執(zhí)行隊(duì)列的需要，并且使用服務(wù)類和約束來滿足那些要求。
過載保護(hù)過載保護(hù)防止服務(wù)器在重負(fù)載下的服務(wù)降級。在過載狀態(tài)下，服務(wù)器以可配置方式拒絕請求。管理員能夠指定閾值隊(duì)列長度，服務(wù)器可以拒絕在其之后的請求。突發(fā)的低優(yōu)先級請求很可能被拒絕。它們還可以為各個服務(wù)類指定更具體的閾值。
JCA 1.5工作管理器(WorkManager)JCA1.5工作管理器API提供了讓適配器調(diào)度服務(wù)器中的工作的方式。該API提供了線程調(diào)度功能性。應(yīng)用程序可以使用工作管理器API來異步地執(zhí)行工作并且接收關(guān)于執(zhí)行狀態(tài)的通知。
工作負(fù)載管理功能描述管理員可以定義調(diào)度策略來規(guī)定特殊目標(biāo)，并且可以表達(dá)約束，如下例所示<response-time-dispatch-policy name＝″Shopping″goal-ms＝″2000″/>
<fair-share-dispatch-policy name＝″GuestShare″percent＝″l″/>
<context-dispatch-policy name＝″ContextShopping″>
<case context＝″subject″value＝″anonymous″policy＝″GuestShare″/>
<case context＝″role″value＝″BigSpender″policy＝″Shopping″/>
</context-dispatch-policy>
<！--該配置跟蹤面對外部網(wǎng)的apache網(wǎng)絡(luò)服務(wù)器的最大處理值-->
<min-threads-constraint name＝″minThreadsForPluginMaxProcesses″count＝″10″/>
然后，部署描述符和RMI描述符可以引用諸如ContextShopping和minThreadsForPluginMaxProcesses的名稱，以將它們施加到入口點(diǎn)。
在調(diào)度邏輯中反映公平份額，從而只要多個服務(wù)類競爭，由每個使用的平均線程數(shù)就與其公平份額成比例。例如，考慮僅僅存在兩個服務(wù)類A和B、其分別具有80和20的公平份額的情形。在充分地請求兩個服務(wù)類期間，假定零考慮時間并且客戶端多于線程，線程將代表A或B工作的概率分別趨向于80％或20％。即使當(dāng)A傾向于使用線程比B更久時，調(diào)度邏輯也確保這樣。
響應(yīng)時間目標(biāo)可以區(qū)別服務(wù)類。系統(tǒng)不試圖滿足各個請求的響應(yīng)時間目標(biāo)。相反地，它通過減去觀察到的平均線程使用時間，為服務(wù)類計(jì)算容許的等待時間。然后，它可以調(diào)度請求，以便每個服務(wù)類的平均等待與其容許等待時間成比例。例如，考慮僅僅存在兩個服務(wù)類A和B，分別具有響應(yīng)時間目標(biāo)2000ms和5000ms，其中各個請求使用線程的時間少得多。在充分地請求該兩個服務(wù)類期間，假定零考慮時間并且客戶端多于線程，系統(tǒng)可以調(diào)度以使平均響應(yīng)時間保持為比率2∶5，使得其是規(guī)定目標(biāo)的普通分?jǐn)?shù)或倍數(shù)。
理解調(diào)度實(shí)現(xiàn)對理解調(diào)度策略是有幫助的。每個服務(wù)類具有增量，并且可以將請求輸入到具有以其間隔而分隔開的虛擬時間戳的事件隊(duì)列中。通過小的增量實(shí)現(xiàn)高優(yōu)先級?？梢匀缦抡f明調(diào)度策略響應(yīng)時間具有以毫秒為單位的屬性goal-ms。增量是((goal-T)Cr)/R其中T是平均線程使用時間，R是到達(dá)率，以及Cr是使響應(yīng)時間目標(biāo)的優(yōu)先級高于公平份額的系數(shù)。
公平份額具有缺省份額的屬性百分比。因此，缺省值為100。增量是Cf/(P R T)其中P是百分比，R是到達(dá)率，T是平均線程使用時間，以及Cf是在優(yōu)先級上使公平份額低于響應(yīng)時間目標(biāo)的系數(shù)。
上下文在多個情況下，將上下文的信息如當(dāng)前用戶或其角色、cookie(應(yīng)用程序)或工作區(qū)域字段映射到命名服務(wù)類。
SubordinateStepResponseTime(次級步驟響應(yīng)時間)具有屬性primary(初級)，其命名PrimaryStepResponseTime。
PrimaryStepResponseTime(初級步驟響應(yīng)時間)
具有以毫秒為單位的屬性goal-ms。與響應(yīng)時間目標(biāo)類似地計(jì)算增量。使用次級步驟與初級步驟的比率，并且減去次級步驟的多個平均線程使用，以獲得容許的等待。對于所有步驟，初級加上次級，將容許的等待除以到達(dá)率，并且乘以響應(yīng)時間系數(shù)。
固定增量具有屬性increment(增量)。
公平份額系數(shù)被選擇為到達(dá)率和平均線程使用時間的最大乘積的大約1000倍。響應(yīng)時間系數(shù)被選擇為使得響應(yīng)時間策略的平均增量僅僅是公平份額策略的平均增量的十分之一。
約束可以定義約束并且將其施加到入口點(diǎn)的集合，在此將其稱作受約束工作集。
最大線程數(shù)限制執(zhí)行來自受約束工作集的請求的并發(fā)線程數(shù)。缺省是不受限制。例如，考慮約束被定義成最大線程數(shù)10并且由3個入口點(diǎn)共享。調(diào)度邏輯確保不多于10個線程正在執(zhí)行來自所組合的三個入口點(diǎn)的請求。
最小線程數(shù)保證服務(wù)器將分配給受約束工作集的請求以避免死鎖的線程數(shù)。缺省值是零。例如，對于從對等者同步調(diào)用的復(fù)制更新請求，最小線程值1是有用的。
容量只有當(dāng)達(dá)到容量時，服務(wù)器才開始拒絕請求。缺省值是零。注意，容量包括來自受約束工作集的、排隊(duì)或執(zhí)行的所有請求。該約束主要是計(jì)劃用于進(jìn)行其自己的流量控制的子系統(tǒng)，如JMS。該約束獨(dú)立于全局隊(duì)列閾值。
不同的調(diào)度策略和約束如下相互作用上面說明了通過使用相同的策略將調(diào)度與其它工作相關(guān)，調(diào)度策略可以基于公平份額和響應(yīng)時間。以有利于響應(yīng)時間調(diào)度的顯著偏袒來調(diào)度公平份額和響應(yīng)時間策略的混合。
最小線程數(shù)約束不增加公平份額。它僅僅與幾乎死鎖的服務(wù)器有關(guān)系。然而，然后在這樣的意義上它將被勝過，即，即使其服務(wù)類最近獲得了多于其的公平份額，系統(tǒng)也調(diào)度來自受到最小線程數(shù)約束的工作集的請求。
最大線程數(shù)約束可能但不一定阻止服務(wù)類獲得其公平份額或者滿足其響應(yīng)時間目標(biāo)。一旦達(dá)到最大線程數(shù)約束，則服務(wù)器將不調(diào)度該約束類型的請求，直至并發(fā)執(zhí)行數(shù)降到該限制之下。然后，服務(wù)器將基于公平份額或響應(yīng)時間目標(biāo)而調(diào)度工作。
可以通過最小線程數(shù)約束和缺省公平份額來解決admin_rmi和admin_html隊(duì)列要求。還通過最小線程數(shù)約束滿足系統(tǒng)隊(duì)列要求。通過設(shè)置最大線程數(shù)等于最小線程數(shù)等于1，來滿足多點(diǎn)傳送(multicast)隊(duì)列要求。這確保了僅僅存在一個處理多點(diǎn)傳送請求的線程，從而保證有序。
功能要求可以以三個級別定義分派策略和約束全局地在config.xml中，針對每個應(yīng)用在weblogic-application.xml中，或者針對特定J2EE模塊在weblogic部署描述符weblogic-ejb-jar.xml和weblogic.xml中?？梢愿鶕?jù)對應(yīng)的標(biāo)簽dispatch-policy(分派策略)、max-threads(最大線程數(shù))和min-threads(最小線程數(shù))來使用這些名稱。max-threads和min-threads標(biāo)簽取這樣的值，即分別地，max-threads-constraint或min-threads-constraint的名稱、或者數(shù)。在weblogic-application.xml中，這些標(biāo)簽指定應(yīng)用范圍的缺省值。在weblogic.xml和weblogic-ejb-jar.xml中，它們在頂層指定組件范圍的缺省值。在weblogic.xml中，允許與web.xml的過濾映射相似的映射，其中針對url模式或servlet(小服務(wù)器程序)名稱，映射命名dispatch-policy、max-threads或min-threads。max-threads-mapping和min-threads-mapping也容許數(shù)值。在weblogic-ejb-jar.xml中，在weblogic-enterprise-bean下的現(xiàn)有dispatch-policy標(biāo)簽值可以是命名的dispatch-policy。為了向后的兼容性，它還可以命名ExecuteQueue(執(zhí)行隊(duì)列)。另外，該系統(tǒng)可以類似于目前的isolation-level(隔離級別)標(biāo)簽而允許dispatch-policy、max-threads和min-threads為一組方法指定命名(或具有用于約束的數(shù)值而未命名)的策略和約束。
下面是來自weblogic-application.xml的示例<weblogic-application>
…<response-time-dispatch-policy>
<name>TradeExecution</name>
<goal-ms>3000</goal-ms>
</response-time-dispatch-policy>
<fair-share-dispatch-policy>
<name>Enquiry</name>
<percent>30</percent>
</fair-share-dispatch-policy>
…<max-threads-constraint>
<name>TradeDB</name>
<count>db.pool.trade</count>
</max-threads-constraint>
<max-threads-constraint>
<name>CustomerInfoDB</name>
<count>db.pool.crm</count>
</max-threads-constraint>
</weblogic-application>
下面是來自RMI描述符的示例，其定義了在部件級別的服務(wù)類<method name＝″getStockQuote(String)″transactional＝″false″dispatch-policy＝″Enquiry″max-threads＝″10″>
</method>
<methodname＝″sellStock(String，int)″dispatch-policy＝″TradeExecution″max-threads＝″TradeDB″transactional＝″true″>
</method>
<methodname＝″getHomePhone(int)″dispatch-policy＝″Enquiry″max-threads＝″CustomerInfoDB″
transactional＝″false″>
</method>
max-threads值可以是數(shù)、命名的max-threads-constraint(最大線程數(shù)約束)或命名的連接池(JDBC或JCA)。如果資源大小是動態(tài)的，則相關(guān)聯(lián)的最小或最大線程數(shù)約束也將是動態(tài)的，并且隨著資源大小的改變而改變。
自動線程計(jì)數(shù)調(diào)整功能描述服務(wù)于優(yōu)先級隊(duì)列的線程池自動地改變其大小，以便最大化吞吐量。管理員不再需要指定諸如threadsIncrease(線程數(shù)增加)和threadsMaximum(線程數(shù)最大)的ExecuteQueueMBean(執(zhí)行隊(duì)列豆)屬性。優(yōu)先級隊(duì)列每2秒監(jiān)測吞吐量，并且使用所收集數(shù)據(jù)來確定是否需要改變線程計(jì)數(shù)。例如，如果在過去，較多線程給出較好的吞吐量，則服務(wù)器將增加線程計(jì)數(shù)。類似地，如果在過去，較少線程數(shù)給出相同的吞吐量，則服務(wù)器將減少線程計(jì)數(shù)。
功能要求用戶輸入不是必要的。服務(wù)器將線程計(jì)數(shù)完全地基于吞吐量歷史記錄和隊(duì)列大小。
減少在啟動時創(chuàng)建的執(zhí)行隊(duì)列的功能描述將不同的執(zhí)行隊(duì)列簡化成單個優(yōu)先級隊(duì)列。在過去，必須創(chuàng)建不同的執(zhí)行隊(duì)列，以便防止死鎖(admin_rmi、無阻塞)，區(qū)分工作(系統(tǒng))的優(yōu)先級，以及實(shí)現(xiàn)有序(多點(diǎn)傳送)。通過將服務(wù)類與排隊(duì)的工作相關(guān)聯(lián)來滿足這些要求。可以將全部工作提交到優(yōu)先級隊(duì)列，并且線程使用時間基于出現(xiàn)在隊(duì)列中的服務(wù)類的類型。
功能要求下表說明可以如何將現(xiàn)有的執(zhí)行隊(duì)列映射到服務(wù)類和約束。
Execute queue fair-share(1-100)response-time-goal min-threadsmax-threadsweblogic.kemel.System 50 None 5 No restrictionweblogic.admin.HTTP 50 None 2 No restrictionweblogic.admin.RMI 50 None 3 No restrictionweblogic.kemel.Non-Blocking 50 None 5 No restrictionJmsDispatcher 50 None 15 No restrictionMulticast 80 None 11
過載保護(hù)功能描述管理員可以配置過載閾值，服務(wù)器在其之后開始節(jié)制(throttling)請求。如下進(jìn)行節(jié)制服務(wù)器拒絕從未設(shè)置最小線程數(shù)約束集合的較低次序的公平份額開始的請求。仍然接受具有高優(yōu)先級的服務(wù)類或具有最小線程數(shù)約束的服務(wù)類。
如果過載狀態(tài)繼續(xù)占上風(fēng)，則由于服務(wù)器不能從過載狀態(tài)恢復(fù)，因此也將拒絕較高優(yōu)先級的請求。將仍然接受具有最小線程數(shù)約束的請求和管理請求。
如果工作被拒絕，則發(fā)送良好定義的錯誤響應(yīng)。對于HTTP發(fā)送“503服務(wù)器忙”錯誤，并且對于RMI，拋出遠(yuǎn)程異常，這將使得群集能夠使客戶端知道要進(jìn)行故障恢復(fù)。
功能要求可以在全局級別或針對每個工作類指定隊(duì)列限制?？梢杂肒ernelMBean屬性表示全局閾值。
工作類可以使用約束中的capacity(容量)元素來定義閾值。這里是關(guān)于如何設(shè)置capacity元素的示例<weblogic-application>
…<capacity-constraint>
<name>myConstraint</name>
<treshold>5000</treshold>
</capacity-constraint>
</weblogic-application>
<methodname＝″*″constraints＝″myConstraint″transactional＝″false″>
</method>
容量約束覆蓋全局閾值。這意味著，即使當(dāng)達(dá)到全局閾值時，服務(wù)器也將繼續(xù)接受請求。僅僅在達(dá)到容量約束的情況下，才將拒絕工作。這對于執(zhí)行其自己的流量控制并且不能使用全局隊(duì)列閾值的子系統(tǒng)是有用的。
HTTP過載操作如果服務(wù)器在群集中，則系統(tǒng)將發(fā)送503錯誤代碼。這將允許插件進(jìn)行故障恢復(fù)。如果服務(wù)器不屬于群集，則系統(tǒng)可以允許客戶配置將被用作過載響應(yīng)的出錯JSP。通過將重定向指定為過載操作，客戶還可以在過載期間將請求重定向到另一服務(wù)器。
RMI過載操作如果服務(wù)器在群集中，則系統(tǒng)拋出ServerOverloadedException(服務(wù)器過載異常)，其是RemoteException(遠(yuǎn)程異常)的子類?？蛻舳藢汛私忉尦煽苫謴?fù)的異常，并且故障恢復(fù)到另一群集節(jié)點(diǎn)。在非群集化的情景中，客戶可以指定用于重定向的備用服務(wù)器。過載期間的RMI請求將被重定向到該備用服務(wù)器。
服務(wù)器將不使用讀線程將拒絕響應(yīng)發(fā)送出去。寫響應(yīng)涉及可能較慢的I/O。使用讀線程寫響應(yīng)將會阻塞所有讀線程，從而防止進(jìn)入的套接字混亂。
子系統(tǒng)可以向內(nèi)核登記過載通知。當(dāng)超過全局隊(duì)列閾值時，內(nèi)核將通知其監(jiān)聽者。該通知可被用于在子系統(tǒng)級別節(jié)制住(throttle back)工作。
功能要求工作管理器可以是應(yīng)用范圍的或全局的。可以在weblogic-application.xml中如下定義應(yīng)用范圍的工作管理器<weblogic-application>
…<workmanager name＝″myWM″>
<fair-share>30</fair-share>
<min-threads>5</min-threads>
<max-threads>25</max-threads>
<capacity>5000</capacity>
</workmanager>
…</weblogic-application>
為了從應(yīng)用程序訪問工作管理器，將在局部環(huán)境(java:comp/env)中查詢其名稱。例如javax.resource.spi.work.WorkManager wm＝
(javax.resource.spi.work.WorkManager)ctx.lookup(″java:comp/env/myWM″)；wm.doWork(work)；系統(tǒng)不為每個工作管理器定義創(chuàng)建線程組。所有工作管理器實(shí)例共享缺省隊(duì)列。它們基于其公平份額或響應(yīng)時間目標(biāo)而獲得優(yōu)先級。
可以使用根據(jù)本公開內(nèi)容的教導(dǎo)而編程的傳統(tǒng)通用或?qū)Ｓ脭?shù)字計(jì)算機(jī)或者微處理器，方便地實(shí)現(xiàn)本發(fā)明?；诒竟_內(nèi)容的教導(dǎo)，熟練的程序員可以容易地準(zhǔn)備適當(dāng)?shù)能浖幋a，這對于軟件領(lǐng)域的技術(shù)人員而言將是顯而易見的。
在一些實(shí)施例中，本發(fā)明包括計(jì)算機(jī)程序產(chǎn)品，其是在其上或其中存儲有指令的存儲介質(zhì)(介質(zhì))，該指令可以用于將計(jì)算機(jī)編程成執(zhí)行本發(fā)明的任何處理。存儲介質(zhì)可以包括但不限于任何類型的盤，包括軟盤、光盤、DVD、CD-ROM、微驅(qū)動器、和磁光盤，ROM、RAM、EPROM、EEPROM、DRAM、VRAM、閃存設(shè)備、磁或光卡、納米系統(tǒng)(包括分子存儲器IC)、或者任何類型的適于存儲指令和/或數(shù)據(jù)的介質(zhì)或設(shè)備。
本發(fā)明的上述描述是為了說明和描述的目的而提供的。它不意欲是窮盡性的或者將本發(fā)明限制為所公開的確切形式。選擇和描述這些實(shí)施例是為了最佳地說明本發(fā)明的原理及其實(shí)際應(yīng)用，從而使本領(lǐng)域的其它技術(shù)人員能夠理解本發(fā)明，以便獲得適于預(yù)期特定應(yīng)用的各種實(shí)施例和各種變型。本發(fā)明的范圍意欲由所附權(quán)利要求及其等價物限定。
版權(quán)通告本專利文獻(xiàn)公開內(nèi)容的一部分包含受到版權(quán)保護(hù)的材料。當(dāng)本專利文獻(xiàn)或者本專利公開內(nèi)容以專利商標(biāo)局專利文件或者記錄形式出現(xiàn)時，版權(quán)所有者不反對任何人對它的傳真復(fù)制，但在其它方面卻無論如何都保留全部版權(quán)。
要求優(yōu)先權(quán)由Anno Langen和Naresh Revanuru于2004年5月20日提交的、申請?zhí)枮?0/572,938、標(biāo)題為SYSTEM AND METHOD FOR APPLICATION SERVERWITH SELF-TUNED THREADING MODEL的美國臨時專利申請(律師事務(wù)所案號BEAS-01560US0)，在此并入引作參考。
由Anno Langen和Naresh Revanuru于2005年5月19日提交的、申請?zhí)枮開_______、標(biāo)題為SYSTEM AND METHOD FOR APPLICATION SERVERWITH SELF-TUNED THREADING MODEL的美國專利申請(律師事務(wù)所案號BEAS-01560US1)，在此并入引作參考。
權(quán)利要求
1.一種用于應(yīng)用服務(wù)器中的自調(diào)整線程模型的系統(tǒng)，包括服務(wù)器，包括一個或更多處理器；一個或更多線程，用于從客戶端接收請求并將這些請求傳遞到處理器；以及優(yōu)先級隊(duì)列，用于根據(jù)份額值將線程分配給多個請求，以優(yōu)化線程的性能。
2.如權(quán)利要求1所述的系統(tǒng)，其中所述服務(wù)器包括多個處理器。
3.如權(quán)利要求1所述的系統(tǒng)，其中根據(jù)按比例時間值，將條目排入優(yōu)先級隊(duì)列。
4.如權(quán)利要求3所述的系統(tǒng)，其中與時間值相比較，根據(jù)計(jì)算出的已經(jīng)使用的線程使用時間，將條目排入隊(duì)列。
5.如權(quán)利要求1所述的系統(tǒng)，其中可以根據(jù)附加配置的約束而將條目排入隊(duì)列。
6.如權(quán)利要求5所述的系統(tǒng)，其中通過將條目排入附加約束隊(duì)列來確定約束。
7.一種用于應(yīng)用服務(wù)器中的自調(diào)整線程模型的方法，包括以下步驟將服務(wù)器配置成根據(jù)份額值在實(shí)體之間共享線程資源；在服務(wù)器處從客戶端接收請求；根據(jù)份額值、并基于每個實(shí)體已經(jīng)使用了多少線程時間，將請求排入優(yōu)先級隊(duì)列；以及從優(yōu)先級隊(duì)列獲得請求，并將它們提供給線程，以便由處理器處理。
8.如權(quán)利要求7所述的方法，其中所述服務(wù)器包括多個處理器。
9.如權(quán)利要求7所述的方法，其中根據(jù)按比例時間值，將條目排入優(yōu)先級隊(duì)列。
10.如權(quán)利要求9所述的方法，其中與時間值相比較，根據(jù)計(jì)算出的已經(jīng)使用的線程使用時間，將條目排入隊(duì)列。
11.如權(quán)利要求7所述的方法，其中可以根據(jù)附加配置的約束而將條目排入隊(duì)列。
12.如權(quán)利要求11所述的方法，其中通過將條目排入附加約束隊(duì)列來確定約束。
13.一種計(jì)算機(jī)可讀介質(zhì)，在其上包括在執(zhí)行時使計(jì)算機(jī)執(zhí)行以下步驟的指令將服務(wù)器配置成根據(jù)份額值在實(shí)體之間共享線程資源；在服務(wù)器處從客戶端接收請求；根據(jù)份額值、并基于每個實(shí)體已經(jīng)使用了多少線程時間，將請求排入優(yōu)先級隊(duì)列；以及從優(yōu)先級隊(duì)列獲得請求，并將它們提供給線程，以便由處理器處理。
14.如權(quán)利要求13所述的計(jì)算機(jī)可讀介質(zhì)，其中所述服務(wù)器包括多個處理器。
15.如權(quán)利要求13所述的計(jì)算機(jī)可讀介質(zhì)，其中根據(jù)按比例時間值，將條目排入優(yōu)先級隊(duì)列。
16.如權(quán)利要求15所述的計(jì)算機(jī)可讀介質(zhì)，其中與時間值相比較，根據(jù)計(jì)算出的已經(jīng)使用的線程使用時間，將條目排入隊(duì)列。
17.如權(quán)利要求13所述的計(jì)算機(jī)可讀介質(zhì)，其中可以根據(jù)附加配置的約束而將條目排入隊(duì)列。
18.如權(quán)利要求17所述的計(jì)算機(jī)可讀介質(zhì)，其中通過將條目排入附加約束隊(duì)列來確定約束。
全文摘要
一種用于具有自調(diào)整線程模型的應(yīng)用服務(wù)器的系統(tǒng)和方法。使用服務(wù)器隊(duì)列作為優(yōu)先級方案，其中包括多個與所接收的請求相關(guān)聯(lián)的條目，并且其允許條目表達(dá)優(yōu)先級或份額值，而不是僅僅線程數(shù)目。仍然保留這樣的靈活性，即在可能希望其的情況下，以原始數(shù)目表達(dá)線程，或者表達(dá)對要使得可用的線程數(shù)目的約束。
文檔編號G06F9/50GK101091164SQ200580001031
公開日2007年12月19日 申請日期2005年5月20日 優(yōu)先權(quán)日2004年5月20日
發(fā)明者安諾·R·蘭根, 納里什·里瓦納魯 申請人:Bea系統(tǒng)公司