專利名稱：負(fù)荷控制裝置及其方法
技術(shù)領(lǐng)域：
本發(fā)明用于一種裝置，該裝置，被配置在客戶機(jī)和服務(wù)器之間，從客戶機(jī)接收請求向服務(wù)器傳送，向客戶機(jī)傳送對于該請求從服務(wù)器返回的應(yīng)答。特別是，涉及請求的調(diào)度。另外，在本說明書中，將著眼于Web服務(wù)器進(jìn)行說明，但是不一定限制本發(fā)明的對于其他服 務(wù)器的應(yīng)用。
背景技術(shù)：
伴隨因特網(wǎng)的普及，已經(jīng)能夠通過網(wǎng)絡(luò)利用各種服務(wù)。郵件、主頁的閱覽、檢索、在線交易、IP電話、點(diǎn)播視頻等，是這些服務(wù)的例子。這些網(wǎng)絡(luò)服務(wù)能夠以各種形態(tài)提供，但是近年來，作為與客戶機(jī)的接口，Web服務(wù)器的利用成為主流。使用Web服務(wù)器的服務(wù)(Web服務(wù))的基本的結(jié)構(gòu)如下。首先，客戶機(jī)對于Web服務(wù)器發(fā)送賦予了識別希望取得的內(nèi)容的URL(統(tǒng)一資源定位器)的請求。當(dāng)Web服務(wù)器接收到請求時(shí)，把與請求中的URL對應(yīng)的內(nèi)容作為應(yīng)答向客戶機(jī)回送。通過該請求-應(yīng)答的重復(fù)，提供Web服務(wù)。作為傳送請求-應(yīng)答的通信協(xié)議，使用HTTP (超文本傳輸協(xié)議)。在本說明書中，把進(jìn)行Web服務(wù)的服務(wù)器系統(tǒng)全體稱為Web服務(wù)器，把在Web服務(wù)器上處理HTTP協(xié)議的功能稱為HTTP服務(wù)器，把生成與請求對應(yīng)的內(nèi)容的功能稱為Web應(yīng)用。另外，作為通過Web服務(wù)提供的內(nèi)容現(xiàn)在廣泛使用視頻和聲音的流。流的基本的結(jié)構(gòu)如下。首先，客戶機(jī)的Web瀏覽器從Web服務(wù)器取得流內(nèi)容的元文件。在元文件中，記述流內(nèi)容的URL。同時(shí)，Web瀏覽器起動(dòng)與元文件的擴(kuò)展符關(guān)聯(lián)的播放器(流再生用程序)。然后，根據(jù)在從Web服務(wù)器取得的元文件中表示的URL，播放器對于流服務(wù)器請求流內(nèi)容的發(fā)送。最后，流服務(wù)器對于播放器發(fā)送流數(shù)據(jù)。在流中服務(wù)器一般在流內(nèi)容的再生控制中使用RTSP(實(shí)時(shí)流協(xié)議)協(xié)議。RTSP協(xié)議是以HTTP協(xié)議為基礎(chǔ)的協(xié)議，在客戶機(jī)和服務(wù)器之間，通過收發(fā)請求和對于請求的應(yīng)答，再生控制流內(nèi)容。作為RTSP的請求能夠使用的主要的方法，有初始設(shè)定(SETUP)、再生(PLAY)、停止(TEARDOffN)等。在RTSP中，因?yàn)橥瑫r(shí)控制多個(gè)流，所以有對話的概念。亦即在RTSP中，把從播放器發(fā)送SETUP請求到發(fā)送TEARD0WN請求、流結(jié)束視作為一次對話。于是，當(dāng)流服務(wù)器從播放器接收SETUP請求時(shí)，發(fā)行唯一的對話ID。把對話ID賦予應(yīng)答，通知客戶機(jī)。通過把通知播放器的對話ID賦予后續(xù)的請求，能夠識別在流服務(wù)器中成為控制對象的對話。隨著Web服務(wù)的普及，為舒適地利用服務(wù)的課題也日益變得明確起來。作為該課題之一，可以舉出服務(wù)利用集中時(shí)的對過剩通信的應(yīng)對。作為服務(wù)利用集中的例子，有由于人氣高的名牌的股票或者票據(jù)的買賣而引起的請求集中、或者災(zāi)害發(fā)生時(shí)的慰問電話等。另外，也有由有惡意的客戶機(jī)大量發(fā)送F5攻擊等的無意義的請求的場合。由于這些原因，當(dāng)向服務(wù)器過剩地發(fā)送請求時(shí)，服務(wù)器的請求處理性能會降低。請求過剩時(shí)服務(wù)器的請求處理性能降低的原因如下。亦即，第一，伴隨服務(wù)器處理不完的請求的接收的，諸如中斷、TCP/IP處理這樣的輸入輸出開銷增加。第二，處理請求的 線程或者進(jìn)程數(shù)增大，作為線程或者進(jìn)程的切換處理所需要的開銷的上下文切換開銷表面化。第三，因?yàn)橄蚩蛻魴C(jī)返回應(yīng)答的應(yīng)答時(shí)間增加，所以等待不來應(yīng)答的客戶機(jī)會中途撤消請求。這些結(jié)果，就會產(chǎn)生服務(wù)器越是擁擠，服務(wù)器的處理性能越是降低這樣的問題。圖I是表示由于請求過剩引起的Web服務(wù)器的處理性能降低的實(shí)驗(yàn)結(jié)果。橫軸表示輸入請求率，縱軸表示通過量。在圖I中，對于某Web服務(wù)器，變化輸入請求率即每單位時(shí)間的請求數(shù)(rps)來發(fā)送請求。然后，測量通過量，即Web服務(wù)器每單位時(shí)間能夠完成的請求數(shù)(rps)。如圖I所示，如果輸入請求率在一定范圍內(nèi)，則通過量對于輸入率成比例(圖I直線(a))。但是，當(dāng)達(dá)到Web服務(wù)器的最大通過量時(shí)，通過量轉(zhuǎn)而降低(圖I直線(C))。所以，即使在接收超過Web服務(wù)器的最大性能的請求的場合，可以說也需要能夠沿圖I虛線(b)、維持Web服務(wù)器的最大性能的技術(shù)。為參考起見，圖2表示出理想的通過量的舉動(dòng)。為防止由于過剩的通信量引起服務(wù)器性能降低，提出了預(yù)先限制向服務(wù)器發(fā)送的請求量的方法。作為限制請求量的指標(biāo)，使用(a)TCP連接數(shù)、(b)服務(wù)器負(fù)荷狀態(tài)、(C)帶寬、(d)并列度等。(a)在使用TCP連接數(shù)的場合，通過決定可同時(shí)連接的TCP連接數(shù)的上限，試圖避免服務(wù)器的過負(fù)荷。在Apache等的通用的HTTP服務(wù)器、負(fù)荷分散系統(tǒng)等中使用。但是，由于請求的種類、客戶機(jī)的線路速度等，對于每一 TCP連接其負(fù)荷有很大的不同。因此，會出現(xiàn)在達(dá)到TCP連接數(shù)的上限前，服務(wù)器已經(jīng)成為過負(fù)荷，或者反之服務(wù)器資源即使有余，由于TCP連接數(shù)已經(jīng)達(dá)到上限，所以不能建立新的TCP連接這樣的問題。(b)在使用服務(wù)器的負(fù)荷狀態(tài)的場合，從CPU占有率、存儲器使用量、應(yīng)答時(shí)間等推測服務(wù)器的負(fù)荷狀態(tài)，判定是否過負(fù)荷，在判定為過負(fù)荷的場合，進(jìn)行新的請求的傳送、拒絕等用于使減輕服務(wù)器的負(fù)荷的通信量控制。但是，因?yàn)樵谂卸ㄊ沁^負(fù)荷后才開始進(jìn)行通信量控制，所以不能避免服務(wù)器暫時(shí)性的降低性能。(C)在使用帶寬的場合，使用整形器等的帶寬控制功能，限制到達(dá)服務(wù)器的通信量。但是，帶寬不是正確測量服務(wù)器的負(fù)荷的指標(biāo)。例如，圖像文件的下載，占用大的帶寬，但是施加給服務(wù)器上的負(fù)荷較小。因此，通過帶寬限制，不容易充分靈活使用服務(wù)器的資源，同時(shí)不容易確實(shí)避免過負(fù)荷。(d)在使用并列度的場合，限制服務(wù)器同時(shí)執(zhí)行的線程或者進(jìn)程數(shù)。由此能夠削減伴隨處理請求的線程或者進(jìn)程數(shù)的增大的上下文切換開銷。作為控制并列度的具體例，有擴(kuò)展HTTP服務(wù)器使在頁單位上限制并列度的文獻(xiàn)(松沼正浩、日比野秀章、佐藤芳樹、光來健一、千葉滋著“改善過負(fù)荷時(shí)的web應(yīng)用的性能惡化的Session-Level Queue Scheduling”,第二屆可靠軟件研討班(DSffj 05),PP- 105-114,2005年I月)。但是，即使在服務(wù)器上控制并列度，也不能避免作為請求處理性能降低的第一原因的、伴隨服務(wù)器處理不完的請求的接收的中斷、TCP/IP處理等的開銷。其結(jié)果，和其他的方法同樣，會發(fā)生過剩通信時(shí)的服務(wù)器的處理性能降低。另外，因?yàn)樾枰狧TTP服務(wù)器或者Web應(yīng)用的變更，所以有向已經(jīng)在運(yùn)用中的服務(wù)的導(dǎo)入障礙高的問題。作為控制并列度的再一例，有流服務(wù)器的對話數(shù)限制。亦即，一般在流服務(wù)器中給能夠同時(shí)保持的對話數(shù)設(shè)定上限。由此，避免伴隨對話數(shù)的增大而產(chǎn)生的服務(wù)器的過負(fù)荷。但是，對話數(shù)的限制，并不是限制通過RTSP進(jìn)行的控制請求的接收。因此，當(dāng)RTSP請求向流服務(wù)器集中時(shí)，會產(chǎn)生對于請求的處理開銷表面化，而流服務(wù)器的處理性能降低 這樣的問題。服務(wù)器的性能降低，如圖3(a)所示，由于通過新請求的接收使中斷、輸入輸出、上下文切換開銷等增加而產(chǎn)生。為了消除這樣的開銷，最大限度地發(fā)揮服務(wù)器的性能，如圖3(b)，在服務(wù)器中的處理結(jié)束的瞬間下一請求到達(dá)是理想的。在該場合，沒有由服務(wù)器處理不完的請求的接收而引起的開銷。另外，在服務(wù)器中不產(chǎn)生從處理結(jié)束到下一請求到達(dá)的空閑的時(shí)間。

發(fā)明內(nèi)容
本發(fā)明是在這樣的背景下做出的，其目的在于，提供一種負(fù)荷控制裝置及其方法，其能夠避免在接收過剩請求時(shí)的服務(wù)器的性能降低。本發(fā)明的負(fù)荷控制裝置，被配置在客戶機(jī)和服務(wù)器之間，居中調(diào)停兩者的請求 應(yīng)答的收發(fā)。亦即，向服務(wù)器發(fā)送從客戶機(jī)接收到的請求，進(jìn)而向客戶機(jī)發(fā)送從服務(wù)器返回的應(yīng)答。此時(shí)，本發(fā)明限制向服務(wù)器發(fā)送完畢的、但是還未從服務(wù)器返回應(yīng)答的請求、亦即等待應(yīng)答請求的數(shù)。為進(jìn)行該限制，如果應(yīng)答等待請求數(shù)達(dá)到了閾值，則對已接收的請求進(jìn)行緩沖，在應(yīng)答等待請求數(shù)降到閾值以下前，使請求的發(fā)送等待。本發(fā)明，為了模擬圖3(b)的理想的請求的到達(dá)，限制服務(wù)器的請求發(fā)送。為簡化說明，首先，圖4(a)表示把應(yīng)答等待請求數(shù)的閾值設(shè)為“I”的場合。為模擬圖3(b)，首先，需要知道服務(wù)器中的線程的執(zhí)行結(jié)束。在本發(fā)明中，從服務(wù)器通過應(yīng)答的接收識別服務(wù)器中的線程的執(zhí)行結(jié)束。然后，返回對于先前發(fā)送的請求的應(yīng)答后才向服務(wù)器發(fā)送下一請求。根據(jù)本發(fā)明，不向服務(wù)器發(fā)送服務(wù)器未處理完的請求。因此，可以削減伴隨請求的接收處理而產(chǎn)生的服務(wù)器的開銷。圖4(a)中，在從服務(wù)器返回應(yīng)答到負(fù)荷控制裝置發(fā)送下一請求之間，在服務(wù)器中產(chǎn)生空閑。為避免該問題，在本發(fā)明中，作為應(yīng)答等待請求數(shù)的閾值，可以設(shè)定比“I”大的值。圖4(b)表示把應(yīng)答等待請求數(shù)的閾值設(shè)為“2”的場合的執(zhí)行例。通過把應(yīng)答等待請求數(shù)取為多個(gè)，增加服務(wù)器上處于可執(zhí)行狀態(tài)的線程數(shù)。因?yàn)楫?dāng)某線程的執(zhí)行結(jié)束時(shí)，能夠立即開始下一線程的執(zhí)行，所以在服務(wù)器的請求中就不容易產(chǎn)生空閑。進(jìn)而，根據(jù)本發(fā)明，能夠不參照服務(wù)器的內(nèi)部信息而從服務(wù)器的外部控制服務(wù)器的負(fù)荷。因此，能夠在不對已經(jīng)運(yùn)行中的服務(wù)器追加或者變更附加的功能的情況下，導(dǎo)入本發(fā)明。另外，根據(jù)本發(fā)明，能夠自動(dòng)調(diào)整應(yīng)答等待請求數(shù)的閾值。最佳應(yīng)答等待請求數(shù)的閾值，根據(jù)服務(wù)器的系統(tǒng)結(jié)構(gòu)(服務(wù)器臺數(shù)、CPU數(shù)等)、應(yīng)用的執(zhí)行時(shí)間而不同。因此，在靜態(tài)地設(shè)定應(yīng)答等待請求數(shù)的閾值的場合，需要事前的性能評價(jià)等、加給負(fù)荷控制裝置的管理者的負(fù)擔(dān)大。
例如，CPU數(shù)是2的服務(wù)器能夠同時(shí)處理的請求數(shù)比CPU數(shù)是I的服務(wù)器多。因此，為使服務(wù)器的通過量最大化，(PU數(shù)是2的場合的應(yīng)答等待請求數(shù)的閾值需要比CPU數(shù)是I的場合設(shè)定得大。另外，當(dāng)著眼于應(yīng)用時(shí)，其執(zhí)行時(shí)間越短，負(fù)荷控制裝置和服務(wù)器之間的發(fā)送延遲相對變得越大。因此，執(zhí)行時(shí)間越短的應(yīng)用，需要把應(yīng)答等待請求數(shù)的閾值設(shè)定得越大，使能夠隱蔽通過發(fā)送延遲時(shí)間引起的空閑時(shí)間。另外，當(dāng)應(yīng)答等待請求數(shù)的閾值變大時(shí)，服務(wù) 器上多重處理的請求數(shù)也增加。因此，當(dāng)閾值變得過大時(shí)，服務(wù)器中的上下文切換開銷增加，引起通過量降低。進(jìn)而，會產(chǎn)生從負(fù)荷控制裝置向服務(wù)器發(fā)送請求到應(yīng)答返回來的應(yīng)答時(shí)間惡化這樣的問題。因此，在本發(fā)明中，測量服務(wù)器的應(yīng)答時(shí)間或者通過量，根據(jù)該測量結(jié)果自動(dòng)調(diào)整應(yīng)答等待請求數(shù)的閾值。由此不依賴服務(wù)器的系統(tǒng)結(jié)構(gòu)或者應(yīng)用，能夠得到希望的應(yīng)答時(shí)間以及通過量。其結(jié)果，能夠減輕應(yīng)答等待請求數(shù)的閾值的設(shè)定中所需要的管理者的負(fù)擔(dān)。如現(xiàn)有技術(shù)a)中所示，一般在Web服務(wù)器中，給TCP連接的同時(shí)連接數(shù)設(shè)置有上限。但是，當(dāng)給TCP連接的同時(shí)連接數(shù)設(shè)置限制時(shí)，有時(shí)根據(jù)應(yīng)答等待請求數(shù)的負(fù)荷控制會不起作用。為解決該問題，在本發(fā)明中，把基于應(yīng)答等待請求數(shù)的負(fù)荷控制，和現(xiàn)有技術(shù)的一種連接集約組合起來使用。所謂連接集約是使用HTTP1. I的Ke印-Alive功能、由多個(gè)客戶機(jī)共享在負(fù)荷控制裝置和服務(wù)器之間建立的TCP連接的技術(shù)。在不使用連接集約的場合，超過現(xiàn)在連接中的客戶機(jī)數(shù)的TCP連接，在負(fù)荷控制裝置和服務(wù)器之間連接。因此，在請求的發(fā)送頻度低的客戶機(jī)嘗試連接多個(gè)的場合等，在超過應(yīng)答等待請求數(shù)前有服務(wù)器的TCP連接數(shù)達(dá)到上限的可能性。其結(jié)果，不能為充分利用服務(wù)器的計(jì)算資源向服務(wù)器供給足夠量的請求。對此，在使用連接集約的場合，能夠在負(fù)荷控制裝置側(cè)進(jìn)行調(diào)整，以使TCP連接數(shù)不超過應(yīng)答等待請求數(shù)。亦即，只要服務(wù)器的TCP連接的同時(shí)連接數(shù)的上限比應(yīng)答等待請求數(shù)的閾值大，就能使TCP連接的同時(shí)連接數(shù)的限制無效。亦即，本發(fā)明是一種負(fù)荷控制裝置，其被配置在客戶機(jī)和服務(wù)器之間，向所述服務(wù)器發(fā)送從所述客戶機(jī)接收到的請求，向所述客戶機(jī)發(fā)送對于該請求從所述服務(wù)器返回的應(yīng)答。這里，本發(fā)明的特征在于，具有對已向所述服務(wù)器發(fā)送完畢但是未從所述服務(wù)器返回應(yīng)答的應(yīng)答等待請求數(shù)進(jìn)行限制的單元，該進(jìn)行限制的單元具有如果應(yīng)答等待請求數(shù)達(dá)到閾值，則臨時(shí)存儲接收到的請求的緩沖器；以及在應(yīng)答等待請求數(shù)下降到低于閾值前使來自所述緩沖器的請求的發(fā)送等待的單元，。例如，所述閾值取比“I”大的值。另外，希望具有以下單元監(jiān)視所述服務(wù)器的執(zhí)行狀況的單元；和根據(jù)所述進(jìn)行監(jiān)視的單元的監(jiān)視結(jié)果在對于所述服務(wù)器的請求的應(yīng)答時(shí)間在允許范圍內(nèi)時(shí)增大所述應(yīng)答等待請求數(shù)的閾值，而在該應(yīng)答時(shí)間超過允許范圍時(shí)減小所述應(yīng)答等待請求數(shù)的閾值的單元。或者希望具有以下單元監(jiān)視所述服務(wù)器的執(zhí)行狀況的單元；根據(jù)該進(jìn)行監(jiān)視的單元的監(jiān)視結(jié)果對于應(yīng)答等待請求數(shù)的每一閾值測定在每單位時(shí)間服務(wù)器已處理的請求數(shù)的通過量的單元；和在對于現(xiàn)在的閾值的通過量高于對于比現(xiàn)在的閾值小的閾值的通過量的場合，增大閾值，而在對于現(xiàn)在的閾值的通過量低于比現(xiàn)在的閾值小的閾值的通過量的場合，減少閾值的單元。另外，此時(shí)，通過具有判定應(yīng)答等待請求數(shù)是否達(dá)到其閾值的單元；和在達(dá)到閾值的場合判定是否增大或者減小閾值的單元，能夠消除在對于服務(wù)器不施加大量負(fù)荷的狀態(tài)下，應(yīng)答等待請求數(shù)的閾值無限制增大的問題。另外，希望具有這樣的單元，亦即，為了使所述服務(wù)器和自己之間的TCP連接的同時(shí)連接數(shù)成為所述應(yīng)答等待請求數(shù)的閾值以下，集約自己和所述客戶機(jī)之間的TCP連接的單元。另外，所述緩沖器可以具有根據(jù)發(fā)送源客戶機(jī)的識別信息優(yōu)先控制請求的單元。

或者，所述緩沖器可以具有根據(jù)是否在請求中的特定的位置或者范圍內(nèi)包含特定的模式來優(yōu)先控制請求的單元?；蛘?，所述緩沖器可以具有根據(jù)請求中的特定的變量是否比預(yù)先設(shè)定的閾值大來優(yōu)先控制請求的單元?；蛘?，所述緩沖器可以具有根據(jù)請求是否被加密來優(yōu)先控制請求的單元。或者，所述緩沖器可以具有對于在規(guī)定時(shí)間以上存儲的請求通知忙消息的單元?；蛘?，所述服務(wù)器是Web服務(wù)器，所述緩沖器可以具有根據(jù)請求的頁顯示的顯示優(yōu)先度來優(yōu)先控制請求的單元?；蛘?，所述請求通過TCP連接從客戶機(jī)向負(fù)荷控制裝置發(fā)送，所述緩沖器可以具有根據(jù)在客戶機(jī)和負(fù)荷控制裝置之間連接的其他的TCP連接的有無或者TCP連接的數(shù)以及該請求是否是TCP連接的最初的請求來優(yōu)先控制請求的單元。或者，具有在對應(yīng)答指示了瀏覽器應(yīng)該自動(dòng)取得的頁構(gòu)成要素的URL的場合，臨時(shí)存儲應(yīng)答發(fā)送目的地的識別信息和該URL的組的單元，所述緩沖器，可以具有根據(jù)請求的發(fā)送源的識別信息和URL的組與臨時(shí)存儲的應(yīng)答發(fā)送目的地的識別信息和URL的組是否一致來優(yōu)先控制請求的單元?；蛘呖梢跃哂懈鶕?jù)所述請求屬于的對話的進(jìn)行狀況來優(yōu)先控制請求的單元?；蛘呖梢跃哂性谝欢ㄆ陂g超高速緩沖存儲在所述服務(wù)器中處理的請求屬于的對話的對話識別信息的單元；和根據(jù)是否具有超高速緩沖存儲的對話識別信息來優(yōu)先控制請求的單元?；蛘撸鼍彌_器可以具有根據(jù)從客戶機(jī)發(fā)送的通信的不正當(dāng)訪問的可疑度來優(yōu)先控制請求的單元。本發(fā)明也可以看作是程序。亦即，本發(fā)明是通過在通用的信息處理裝置中安裝而使該通用的信息處理裝置實(shí)現(xiàn)與本發(fā)明的負(fù)荷控制裝置的功能相應(yīng)的功能的程序。另外，本發(fā)明也可以看作是記錄介質(zhì)。亦即本發(fā)明是記錄本發(fā)明的程序的記錄介質(zhì)。本發(fā)明的程序，通過被記錄在本發(fā)明的記錄介質(zhì)中，所述通用的信息處理裝置能夠使用該記錄介質(zhì)安裝本發(fā)明的程序。或者，也能夠從保存本發(fā)明的程序的服務(wù)器通過網(wǎng)絡(luò)將本發(fā)明的程序直接安裝在所述通用的信息處理裝置中。由此，用通用的信息處理裝置，就能夠?qū)崿F(xiàn)本發(fā)明的負(fù)荷控制裝置。另外，可以把本發(fā)明看作是本發(fā)明的負(fù)荷控制裝置執(zhí)行的負(fù)荷控制方法的發(fā)明。亦即，本發(fā)明是一種負(fù)荷控制方法，其特征在于，具有限制已向所述服務(wù)器發(fā)送完畢但是未從所述服務(wù)器返回應(yīng)答的應(yīng)答等待請求數(shù)的步驟，該進(jìn)行限制的步驟具有以下步驟如果應(yīng)答等待請求數(shù)達(dá)到了閾值，則將接收到的請求臨時(shí)存儲在緩沖器中的步驟；和在應(yīng)答等待請求數(shù)下降到低于閾值前使來自所述緩沖器的請求的發(fā)送等待的步驟。例如所述閾值取比“I”大的值。另外，希望具有以下步驟監(jiān)視所述服務(wù)器的執(zhí)行狀況的步驟；和根據(jù)所述進(jìn)行監(jiān)視的步驟的監(jiān)視結(jié)果在對于所述服務(wù)器的請求的應(yīng)答時(shí)間在允許范圍內(nèi)時(shí)增大所述應(yīng)答等待請求數(shù)的閾值，而在該應(yīng)答時(shí)間超過允許范圍的場合減小所述應(yīng)答等待請求數(shù)的閾值的步驟?；蛘呦Ｍ哂幸韵虏襟E監(jiān)視所述服務(wù)器的執(zhí)行 狀況的步驟；根據(jù)該進(jìn)行監(jiān)視的步驟的監(jiān)視結(jié)果對于應(yīng)答等待請求數(shù)的每一閾值測定在每單位時(shí)間服務(wù)器已處理的請求數(shù)的通過量的步驟；和在對于現(xiàn)在的閾值的通過量高于對于比現(xiàn)在的閾值小的閾值的通過量的場合，增大閾值，而在對于現(xiàn)在的閾值的通過量低于對于比現(xiàn)在的閾值小的閾值的通過量的場合，增小閾值的步驟。另外，此時(shí)，希望具有判定應(yīng)答等待請求數(shù)是否達(dá)到其閾值的步驟；和在達(dá)到閾值的場合判定是否增大或者減小閾值的步驟。另外，希望具有這樣的步驟，亦即為了使所述服務(wù)器和自己之間的TCP連接的同時(shí)連接數(shù)成為所述應(yīng)答等待請求數(shù)的閾值以下，集約自己和所述客戶機(jī)之間的TCP連接的步驟。根據(jù)本發(fā)明，能夠避免接收過剩請求時(shí)服務(wù)器的性能降低。此時(shí)，因?yàn)橐材苁褂糜谶m當(dāng)控制的閾值的設(shè)定自動(dòng)化，所以能夠減輕裝置管理者的負(fù)擔(dān)。


圖I是用于說明通過過剩請求引起的服務(wù)器的處理性能降低的圖。圖2是表示理想的通過量的舉動(dòng)的圖。圖3是表示過剩請求時(shí)的服務(wù)器的動(dòng)作以及請求到達(dá)服務(wù)器的理想的狀態(tài)的圖。圖4是表示通過本發(fā)明請求到達(dá)服務(wù)器的狀態(tài)的圖。圖5是表示第一實(shí)施形態(tài)的全體結(jié)構(gòu)圖。圖6是表示第一實(shí)施形態(tài)的負(fù)荷控制裝置的處理過程的流程圖。圖7是表示第一實(shí)施形態(tài)的請求接收處理的執(zhí)行過程的流程圖。圖8是表示第一實(shí)施形態(tài)的應(yīng)答接收處理的執(zhí)行過程的流程圖。圖9是表示基于RTSP請求的方法名的類分類的一例的圖。圖10是第二實(shí)施形態(tài)的負(fù)荷控制裝置的方框結(jié)構(gòu)圖。圖11是表示第二實(shí)施形態(tài)的請求接收部的處理過程的流程圖。圖12是表示請求表的圖。圖13是表示第二實(shí)施形態(tài)的請求發(fā)送部的處理過程的流程圖。圖14是表示服務(wù)器側(cè)套接字表的圖。圖15是表示第二實(shí)施形態(tài)的應(yīng)答接收部的處理過程的流程圖。圖16是表示第二實(shí)施形態(tài)的應(yīng)答發(fā)送部的處理過程的流程圖。圖17是表示第二實(shí)施形態(tài)的調(diào)度部的處理過程的流程圖。圖18是表示證實(shí)本發(fā)明的效果的實(shí)驗(yàn)的結(jié)構(gòu)的圖。
圖19是表示用于實(shí)驗(yàn)的服務(wù)器以及負(fù)荷控制裝置的結(jié)構(gòu)表的圖。圖20是表示本發(fā)明的效果的圖。圖21是表示用于證實(shí)自動(dòng)調(diào)整本發(fā)明的應(yīng)答等待請求數(shù)的效果的實(shí)驗(yàn)的服務(wù)器以及負(fù)荷控制裝置的結(jié)構(gòu)表的圖。圖22是表示對于應(yīng)答等待請求數(shù)的閾值的設(shè)定值的通過量的變化的圖。圖23是表示自動(dòng)調(diào)整本發(fā)明的應(yīng)答等待請求數(shù)的閾值的效果的圖。

圖24是表示進(jìn)行本發(fā)明的請求的優(yōu)先控制的效果的圖。
具體實(shí)施例方式(第一實(shí)施形態(tài))參照

本發(fā)明的第一實(shí)施形態(tài)。圖5是表示本發(fā)明的第一實(shí)施形態(tài)的框圖。本發(fā)明由發(fā)行請求的客戶機(jī)1-1 1-n ;返回與請求對應(yīng)的應(yīng)答的服務(wù)器4 ;以及居中調(diào)停請求以及應(yīng)答的負(fù)荷控制裝置3組成。另外，服務(wù)器4可以是Apache等的軟件模塊，也可以是CPU和存儲器等物理資源與負(fù)荷控制裝置3獨(dú)立的硬件模塊。另外，也可以把本負(fù)荷控制裝置3連接在兩個(gè)以上的服務(wù)器4上，用一個(gè)負(fù)荷控制裝置3對于多個(gè)服務(wù)器4進(jìn)行負(fù)荷控制。進(jìn)而，負(fù)荷控制裝置3，也可以擴(kuò)展安裝反向Proxy、Web加速器、Firewall、負(fù)荷分散系統(tǒng)等的現(xiàn)有技術(shù)。在負(fù)荷控制裝置3中，監(jiān)視已向服務(wù)器發(fā)送完畢但是尚未返回應(yīng)答的請求數(shù)即應(yīng)答等待請求數(shù)。在應(yīng)答等待請求數(shù)超過規(guī)定的閾值的場合，緩沖存儲接收到的請求。然后，在應(yīng)答等待請求數(shù)降低到低于閾值前，暫緩請求的發(fā)送。圖6表示負(fù)荷控制裝置3的處理過程。當(dāng)開始執(zhí)行時(shí)，負(fù)荷控制裝置3首先等待到接收消息(SI)。這里，假定負(fù)荷控制裝置接收的消息僅有請求或者應(yīng)答兩種。當(dāng)接收到消息時(shí)(S2)，在該消息是請求的場合起動(dòng)請求接收處理(S3)，在是應(yīng)答的場合，起動(dòng)應(yīng)答接收處理(S4)。圖7表示請求接收處理的執(zhí)行過程。在接收請求的場合，負(fù)荷控制裝置3在緩沖器中存儲該請求(S10)。接著，判定應(yīng)答等待請求數(shù)是否不到閾值(S11)。另外，在本實(shí)施形態(tài)中，假定應(yīng)答等待請求數(shù)的閾值，是靜態(tài)地給予了任意的值。在閾值以上的場合(Sll)，暫緩向服務(wù)器4的請求的發(fā)送，結(jié)束本處理。在不到閾值的場合(Sll)，從緩沖器選擇一個(gè)請求取出(S12)。接著，在給應(yīng)答等待請求數(shù)加I后(S13)，向服務(wù)器發(fā)送請求(S14)。接著，圖8表示應(yīng)答接收處理的執(zhí)行過程。首先，把已接收到的應(yīng)答向發(fā)送該應(yīng)答的請求的客戶機(jī)返回(S20)。接著，把應(yīng)答等待請求數(shù)減I (S21)。然后，判定緩沖器中是否存在等待發(fā)送請求(S22)。在請求不存在的場合(S22)，結(jié)束該處理。在請求存在的場合
(522)，和請求接收處理同樣，嘗試請求的發(fā)送。亦即，判定應(yīng)答等待請求數(shù)是否不到閾值
(523)。在閾值以上的場合(S23)，暫緩向服務(wù)器4發(fā)送請求，結(jié)束本處理。在不到閾值的場合(S23)，從緩沖器中選擇一個(gè)請求取出(S24)。接著，在給應(yīng)答等待請求數(shù)加I后(S25)，向服務(wù)器4發(fā)送請求(S26)。這樣，在應(yīng)答等待請求數(shù)超過閾值的場合，通過暫緩請求的發(fā)送，不向服務(wù)器4發(fā)送過剩的請求。另外，在超過閾值的場合，通過在緩沖器中存儲請求，能夠吸收瞬時(shí)的請求量的增減。其結(jié)果，能夠?qū)τ诜?wù)器4穩(wěn)定地供給請求。
作為調(diào)度緩沖器中的請求的執(zhí)行順序的算法，可以使用單一的隊(duì)列根據(jù)FIFO(先進(jìn)先出)處理請求。另外也可以使用多個(gè)隊(duì)列根據(jù)請求的重要性或者要求質(zhì)量實(shí)施優(yōu)先控制。在該場合，根據(jù)一定的規(guī)則把請求分類，根據(jù)分類結(jié)果設(shè)定優(yōu)先控制的參數(shù)(例如優(yōu)先級、重要性、超時(shí)時(shí)間)等。這里，把根據(jù)一定的規(guī)則分類的結(jié)果產(chǎn)生的請求的集合定義為類。然后按類別在隊(duì)列中存儲請求，根據(jù)優(yōu)先控制參數(shù)調(diào)度各隊(duì)列間的請求取出順序。作為該調(diào)度算法，例如可以使用從屬于優(yōu)先級最高的類的請求進(jìn)行處理的Priority Queuing、根據(jù)每類的重要性進(jìn)行速率控制的Waighted Fair Queuing、Waighted Round Robin等已有的優(yōu)先調(diào)度算法。另外，代替隊(duì)列，可以使用按照到超時(shí)的時(shí)間長度為升序那樣來排列請求的EDF(Earliest Deadline First)。通過進(jìn)行請求的優(yōu)先控制,能夠優(yōu)先在服務(wù)器4中處理重要的或者時(shí)間制約嚴(yán)格的請求。 另外，在緩沖器中存儲請求時(shí)，緩沖器中的請求數(shù)有時(shí)達(dá)到可能存儲的最大數(shù)。在該種場合，選擇緩沖器中的任何一個(gè)請求，執(zhí)行以下的任何一種。 廢棄廢棄請求。 拒絕停止向服務(wù)器4發(fā)送請求。然后，從負(fù)荷控制裝置3向客戶機(jī)1-1 1-n發(fā)送忙消息。和請求的廢棄不同，可以向客戶機(jī)1-1 1-n明示請求失敗的原因是請求集中。 轉(zhuǎn)發(fā)向過負(fù)荷時(shí)用的待機(jī)服務(wù)器轉(zhuǎn)發(fā)請求。由此，代替負(fù)荷集中的服務(wù)器4，待機(jī)服務(wù)器可以處理該請求。另外，也可以給緩沖器中的各請求設(shè)定超時(shí)。在檢測到達(dá)到超時(shí)的請求的場合，也可以和緩沖器中的請求數(shù)達(dá)到可存儲的最大數(shù)的場合實(shí)施同樣的處理。在實(shí)施請求的優(yōu)先控制的場合，根據(jù)一定的規(guī)則把請求分成類，根據(jù)給每一類設(shè)定的優(yōu)先級、重要性、超時(shí)時(shí)間等的參數(shù)進(jìn)行調(diào)度。為高效率提供Web服務(wù)，只要根據(jù)以下表示的規(guī)則分類請求屬于的類即可。另外，可以使用這些實(shí)施例的僅只任何一個(gè)，也可以組合多個(gè)實(shí)施例對類進(jìn)行分類。 基于客戶機(jī)識別信息的類分類 基于請求的內(nèi)容的類分類 基于有無加密的類分類 基于頁處理的進(jìn)行狀況的類分類 基于對話處理的進(jìn)行狀況的類分類 基于不正當(dāng)?shù)目梢啥鹊念惙诸?基于客戶機(jī)識別信息的類分類)根據(jù)請求的發(fā)送源客戶機(jī)對類進(jìn)行分類。以下表示實(shí)施例。 基于發(fā)送源IP地址的類分類在作為發(fā)送的協(xié)議使用TCP/IP的場合，能夠從發(fā)送源IP地址識別客戶機(jī)。所以，通過基于發(fā)送源IP地址選擇隊(duì)列，能夠優(yōu)先化或者非優(yōu)先化來自特定的客戶機(jī)的請求。例如，在負(fù)荷控制裝置中預(yù)先登記管理者的主機(jī)的IP地址。接著，當(dāng)負(fù)荷控制裝置接收請求時(shí)，如果是來自已登記的主機(jī)的請求，則在高優(yōu)先的類中存儲。由此，能夠保護(hù)由管理者對于服務(wù)器的訪問。 基于User-Agent字段的類分類在服務(wù)器是Web服務(wù)器的場合，客戶機(jī)可以根據(jù)HTTP協(xié)議在請求的頭標(biāo)中包含User-Agent字段。在User-Agent字段中，存儲發(fā)行請求的客戶機(jī)應(yīng)用的信息。因此，在負(fù)荷控制裝置中，通過根據(jù)接收到的請求的User-Agent的種類分成類，可以使來自使用該Web服務(wù)專用的瀏覽器的客戶機(jī)的請求優(yōu)先化，或者另外可以非優(yōu)先化通過檢索機(jī)器人等以機(jī)械方式發(fā)行的請求。 基于用戶ID的類分類Web服務(wù)器，為識別客戶機(jī)，根據(jù)客戶機(jī)發(fā)行用戶ID，可以指示在HTTP請求中包含給客戶機(jī)發(fā)行的用戶ID。該用戶ID，可以使Cookie字段、URL的查詢、請求的體內(nèi)包含用戶ID。因此，在負(fù)荷控制裝置中，預(yù)先登記希望優(yōu)先化(或者非優(yōu)先化)的客戶機(jī)的用戶ID。接著，根據(jù)在HTTP請求中包含的用 戶ID和登記的用戶ID是否一致選擇類。由此，可以優(yōu)先化來自支付了追加費(fèi)用的客戶機(jī)的請求，反之，或者非優(yōu)先化來自在黑名單上記載的客戶機(jī)的請求。(基于請求的內(nèi)容的類分類)根據(jù)在請求中的頭標(biāo)或者內(nèi)容的任意的位置(在是HTTP請求的場合，例如請求行、各字段等)是否和任意的模式一致、請求中的任意的變量是否超過閾值，來選擇存儲請求的類。以下列舉使用HTTP協(xié)議的場合的實(shí)施例。另外，在以下的實(shí)施例中將模式以正規(guī)表現(xiàn)記述在“ ”中。 基于方法的類分類在HTTP中，根據(jù)對于資源的操作內(nèi)容，準(zhǔn)備多種方法。例如，為取得資源使用GET方法，為向服務(wù)器發(fā)送數(shù)據(jù)，使用POST方法。在在線購物或者個(gè)人信息的更新等的重要的處理中，因?yàn)楸仨毾蚍?wù)器發(fā)送用戶輸入的信息，所以不用GET方法而使用POST方法。這里，在HTTP中，方法名用請求中的請求行指定。因此，通過把請求行的方法名和模式“POST” 一致的請求分類到高優(yōu)先的類中，能夠優(yōu)先處理重要度高的請求。 基于文件的種類的類分類有時(shí)希望非優(yōu)先化對于動(dòng)態(tài)內(nèi)容那樣負(fù)荷高的處理的請求。從被請求的文件名能夠識別是動(dòng)態(tài)內(nèi)容還是靜態(tài)內(nèi)容。例如，在作為動(dòng)態(tài)內(nèi)容使用CGI的場合，其請求的文件名的后綴是.Cgi0因此，在非優(yōu)先化CGI的場合，把對于請求的URL和模式cgi ” 一致的文件的請求分在低優(yōu)先級的類中。 基于文件長度的類分類在希望非優(yōu)先化試圖上載非常大的長度的文件那樣的請求的場合，給表示HTTP頭標(biāo)的請求長度的Content-Length字段的值設(shè)定閾值,把超過閾值的請求分在低優(yōu)先級的類中。(基于有無加密的類分類)根據(jù)請求是否被加密選擇請求的類。一般，被加密后發(fā)送的請求比不加密發(fā)送的請求包含重要的信息。因此，通過把被加密的請求分類到高優(yōu)先的類中，能夠保護(hù)重要的請求。例如，在Web服務(wù)中，作為請求的發(fā)送方法，可以選擇不加密的HTTP通信、加密的HTTPS通信的任何一種。此時(shí)，通過TCP連接的連接目的地端口號碼識別是HTTP通信還是HTTPS通信。因此，在優(yōu)先化被加密的請求的場合，只要把從在HTTPS通信用的端口上連接的TCP連接發(fā)送的請求分類到高優(yōu)先的類中即可。(基于頁處理的進(jìn)行狀況的類分類)在Web服務(wù)中，有時(shí)客戶機(jī)的瀏覽器需要多個(gè)請求顯示I頁。在本說明書中把為顯示I頁的請求的重復(fù)稱為頁處理。頁處理的基本的進(jìn)行步驟如下。首先，客戶對于瀏覽器輸入成為希望取得的頁的路徑的資源(以下稱頁路徑資源)的URL。接著，瀏覽器根據(jù)輸入的URL，對于Web服務(wù)器發(fā)送請求，取得頁路徑資源。此時(shí)，在頁路徑資源中指示為頁顯示所需要的其他的資源的URL。接著，瀏覽器對于指示的URL自動(dòng)發(fā)行請求。遞歸重復(fù)上述過程直到取得為頁顯示所需要的全部資源。下面表示基于頁處理的進(jìn)行的類分類的實(shí)施例。 基于URL的類分類通過優(yōu)先處理對于頁的顯示不可缺的資源的請求，在服務(wù)器擁擠時(shí)用最小必要限度的頁結(jié)構(gòu)能夠向更多的客戶機(jī)提供服務(wù)。例如，在Web服務(wù)器中，在Web服務(wù)器的不同的目錄中保存頁顯示不可缺的資源和不是這樣的資源。于是，在負(fù)荷控制裝置中，只要使用上述“基于請求的內(nèi)容的類分類”，把對于保存頁顯示不可缺的資源的目錄屬下的資源的請求分類到優(yōu)先級高的類中即可。

基于是否是對于頁路徑資源的請求的類分類通過把對于頁路徑資源的請求分類到低優(yōu)先級的類中，優(yōu)先處理已經(jīng)繼續(xù)中的頁處理。由此，能夠消除服務(wù)器擁擠時(shí)頁處理中的請求中途失敗、在客戶機(jī)的瀏覽器上顯示不完全的頁這樣的問題。特別，在作為調(diào)度緩沖器中的請求的算法使用上述PriorityQueuing的場合,只要頁處理中的請求在緩沖器中，就不處理對于頁路徑資源的請求。因此，服務(wù)器擁擠時(shí)能夠有效地封鎖開始新的頁處理。用于低優(yōu)先化對于頁路徑資源的請求的方法如下。 是否是TCP連接的最初的請求在HTTP1. I中，能夠用一個(gè)TCP連接收發(fā)多個(gè)請求 應(yīng)答。因此，為了頁顯示在瀏覽器自動(dòng)發(fā)送請求的場合，通常，再利用在對于頁路徑資源的取得中使用的TCP連接。因此，通過在連接TCP連接后把第二個(gè)以后的請求分類到高優(yōu)先的類中，能夠保護(hù)正繼續(xù)的頁處理。另外，瀏覽器也能夠?qū)τ谕环?wù)器連接多個(gè)連接，用多個(gè)連接并列接收頁顯示所需要的資源。因此，即使是連接TCP連接后最初的資源，如果存在從同一客戶機(jī)已經(jīng)連接在服務(wù)器(或者負(fù)荷控制裝置)上的TCP連接，則也可以把其請求例外地分類到高優(yōu)先的類中。負(fù)荷控制裝置中的具體的執(zhí)行過程如下。I)當(dāng)從服務(wù)器接收應(yīng)答時(shí)，在表(客戶機(jī)識別信息表)中追加成為返回目的地的客戶機(jī)的識別信息。在表中已經(jīng)存在該客戶機(jī)的識別信息的場合，可以省略該步驟。2)當(dāng)接收請求時(shí)，參照客戶機(jī)識別信息表。3)在表中有作為該請求的發(fā)送源的客戶機(jī)的識別信息的場合，把該請求分類到高優(yōu)先的類中。另一方面，在表中沒有的場合，把該請求分類到低優(yōu)先級的類中。4)當(dāng)從同一客戶機(jī)連接的TCP連接全部被切斷時(shí)，從客戶機(jī)識別信息表中刪除該客戶機(jī)的識別信息。 頁路徑資源的URL的登記在負(fù)荷控制裝置中預(yù)先登記頁路徑資源的URL的一覽表。然后，使用上述的“基于請求的內(nèi)容的類分類”對類進(jìn)行分類。亦即，負(fù)荷控制裝置，當(dāng)接收請求時(shí)，首先比較請求的URL和表中的URL。然后，如果該請求的URL和頁路徑資源的URL —致，則把該請求分類到低優(yōu)先的類中。
URL的超高速緩沖存儲在從服務(wù)器返回的應(yīng)答中指示瀏覽器應(yīng)該自動(dòng)取得的資源的URL的場合，把該URL超高速緩沖存儲一定時(shí)間，優(yōu)先化對于該URL的請求。在HTTP協(xié)議中，通過HTML文件的Src標(biāo)簽等，指示瀏覽器應(yīng)該自動(dòng)取得的資源的URL。因此，負(fù)荷控制裝置中的執(zhí)行過程如下。I)在應(yīng)答的文件類型是HTML文件的場合，在內(nèi)容中檢索和模式“Src =” 一致的
字符串。2)在和模式“Src = ”一致的字符串存在的場合，接著抽出繼模式“Src =”之后的URL。3)把抽出的URL和應(yīng)答發(fā)送 目的地的客戶機(jī)識別信息的組超高速緩沖存儲一定期間。4)并用上述的“基于發(fā)送源客戶機(jī)識別信息的類分類”和“基于請求的內(nèi)容的類分類”，在從被超高速緩沖存儲的客戶機(jī)接收對于被超高速緩沖存儲的URL的請求的場合，把該請求分類到高優(yōu)先的類中。(基于對話處理的進(jìn)行狀況的類分類)在Web服務(wù)器中，有通過跨多個(gè)頁進(jìn)行閱覽或者信息輸入才結(jié)束一個(gè)服務(wù)的情況。例如，在在線購物中，進(jìn)行要購買的商品的選擇或者客戶信息的輸入，最后通過購買內(nèi)容的確認(rèn)，才結(jié)束購買手續(xù)。在本說明書中，在到結(jié)束需要多個(gè)頁的服務(wù)中，把客戶機(jī)取得開始頁到取得最后的頁結(jié)束稱為對話。對話，在進(jìn)行金錢和物品或者交易、或者個(gè)人信息的更新等重要的處理的場合使用。但是，當(dāng)服務(wù)器擁擠時(shí)，有對話大部分不結(jié)束這樣的問題。這是因?yàn)楫?dāng)在服務(wù)器上并列處理的對話數(shù)增加時(shí)，在對話間競爭服務(wù)器資源，中途失敗的對話增加的緣故。因此，在負(fù)荷控制裝置中，即使服務(wù)器擁擠時(shí)，也根據(jù)請求屬于的對話的進(jìn)行狀況對類進(jìn)行分類，以使其能夠維持高的對話通過量。在進(jìn)行對話處理的場合，Web服務(wù)器需要識別接收到的請求屬于哪個(gè)對話。因此，在對話處理中，使用對話ID等的對話識別信息。例如，Web服務(wù)器，當(dāng)接收到對于對話的開始頁的請求時(shí)，對于每一對話發(fā)行唯一的對話ID，連同應(yīng)答一起向客戶機(jī)返回。在典型的Web服務(wù)器中，在HTTP應(yīng)答的Set-Cookie字段中存儲對話ID。接著，客戶機(jī)把從服務(wù)器通知的對話ID包含在請求中來向服務(wù)器發(fā)送。此時(shí)，在通過應(yīng)答的Set-Cookie字段通知對話ID的場合，在請求的Cookie字段中存儲對話ID。Web服務(wù)器通過請求中的對話ID可識別該請求屬于的對話。另外，如上述，在流服務(wù)器中使用的RTSP，在標(biāo)準(zhǔn)中具有對話的概念。亦即，當(dāng)通過SETUP請求開始對話時(shí)，發(fā)行對話ID，賦予以后的請求 應(yīng)答。在RTSP中，在RTSP頭標(biāo)的Session字段中存儲對話ID。在本實(shí)施例的負(fù)荷控制裝置中，首先，把請求中的對話ID作為關(guān)鍵字，評價(jià)該請求屬于的對話的進(jìn)行狀況。例如，在一律優(yōu)先化屬于已經(jīng)開始后的對話的請求的場合，如果是HTTP協(xié)議則檢查請求中的Cookie字段等的有無，如果是RTSP協(xié)議則檢查請求中的Session字段的有無，判定對話ID是否被包含在請求中。然后，把包含對話ID的請求分類到高優(yōu)先的類中。由此，能夠優(yōu)先地用服務(wù)器處理開始后的對話。特別在作為調(diào)度緩沖器中的請求的算法使用上述的Priority Queuing的場合,只要在緩沖器中存在屬于繼續(xù)中的開始后的對話，則不處理要求新的對話開始的請求。因此，能夠在服務(wù)器擁擠時(shí)有效地封鎖新的對話處理的開始。
進(jìn)而，因?yàn)楸苊饬擞袗阂獾目蛻魴C(jī)的不正當(dāng)?shù)厥褂脤υ扞D，所以也能夠驗(yàn)證對話ID的有效性。下面，表示負(fù)荷控制裝置中的執(zhí)行過程。I)檢查來自服務(wù)器的應(yīng)答，如果是HTTP協(xié)議，則檢查Set-Cookie字段等，如果是RTSP協(xié)議，則檢查Session字段，判定是否新發(fā)行了對話ID。2)在新發(fā)行了對話ID的場合，把該對話ID超高速緩沖存儲一定期間。3)驗(yàn)證在負(fù)荷控制裝置中接收到的請求中是否包含有對話ID。4)在請求中包含對話ID的場合，驗(yàn)證是否和超高速緩沖存儲的對話ID的某一個(gè)—致。

5)在和任何一個(gè)對話ID都不一致的場合，該請求的對話ID無效，不需要把該請求分類到高優(yōu)先的類中。另外，作為對于對話ID從超高速緩沖存儲器遺漏的對策，在請求具有的對話ID在超高速緩沖存儲器中不存在的場合，也可以在服務(wù)器中處理該請求的時(shí)刻，在超高速緩沖存儲器中再登記該請求具有的對話ID。作為被超高速緩沖存儲的對話識別信息，也可以使用請求的發(fā)送源IP地址、用戶ID等的客戶機(jī)識別信息。例如，代替對話ID，通過超高速緩沖存儲在服務(wù)器中已處理請求的客戶機(jī)的IP地址，以發(fā)送源IP地址單位優(yōu)先化已開始的對話，以下表示本方法的實(shí)施例。I)把負(fù)荷控制裝置從服務(wù)器接收的應(yīng)答的發(fā)送目的地客戶機(jī)的IP地址超高速緩沖存儲一定時(shí)期。2)驗(yàn)證負(fù)荷控制裝置接收到的請求的發(fā)送源IP地址是否與超高速緩沖存儲的某個(gè)對話ID —致。在一致的場合，認(rèn)為是來自服務(wù)器中的處理開始被認(rèn)可的客戶機(jī)的請求，把該請求分類到高優(yōu)先的類中。和使用對話ID的場合比較，本方法有連不需要優(yōu)先化的對話也進(jìn)行優(yōu)先化的可能性這樣的缺點(diǎn)。例如，在多個(gè)客戶機(jī)通過同一 Proxy訪問負(fù)荷控制裝置的場合，負(fù)荷控制裝置接收的請求的發(fā)送源IP地址，全部成為Proxy的IP地址。因此，在訪問同一 Proxy的客戶機(jī)的任何一個(gè)中開始處理的場合，來自其他客戶機(jī)的請求也被分類到高優(yōu)先的類中。另一方面，作為使用發(fā)送源IP地址的優(yōu)點(diǎn)，可以舉出計(jì)算費(fèi)用小，設(shè)定容易等。也可以把對話識別信息的超高速緩沖存儲器應(yīng)用于上述基于頁處理的進(jìn)行狀況的類分類中的“基于是否是對于頁路徑資源的請求的類分類”。亦即，頁處理，可認(rèn)為是以I頁結(jié)束的特殊的對話處理。所以，把超高速緩沖存儲對話識別信息的期間限制在一個(gè)頁處理結(jié)束所需要的時(shí)間(典型的是數(shù)秒)。由此，在客戶機(jī)訪問新的頁前，超高速緩沖存儲器中的對話識別信息被刪去。其結(jié)果，對于新頁的頁路徑資源的請求，因?yàn)樵诔咚倬彌_存儲器中不存在對話識別信息，所以分類到低優(yōu)先的類中。然后，在服務(wù)器中處理對于該頁路徑資源的請求的時(shí)刻，通過在超高速緩沖存儲器中再登記對話識別信息，可以把對于頁顯示所需要的剩余的資源的請求分類到高優(yōu)先的類中。也可以不根據(jù)對話ID而根據(jù)請求的URL評價(jià)對話的進(jìn)行狀況。例如，在Web服務(wù)器中，將構(gòu)成對話的各頁的資源預(yù)先保存到對于每一頁不同的目錄中。由此，通過在資源的URL中表示的目錄，能夠識別請求所要求的資源屬于的頁。因此，在負(fù)荷控制裝置中，通過使用上述的“基于請求的內(nèi)容的類分類”，能夠?qū)τ谒蟮馁Y源屬于的每一頁把請求分類到類中。此時(shí)，把離對話開始越近的頁，將其優(yōu)先級設(shè)定得越低。在服務(wù)器是基于RTSP的流服務(wù)器的場合，也可以根據(jù)請求的方法評價(jià)對話的進(jìn)行狀況。如上述，在RTSP中，根據(jù)流的控制內(nèi)容，準(zhǔn)備了 SETUP、PLAY、TEARD0WN等的方法。這些方法，可以分類為在對話確立以前使用、和在對話確立以后使用。因此，通過把在對話確立以后使用的方法的請求分類到優(yōu)先級高的類中，能夠優(yōu)先化確立結(jié)束的對話。圖9表示在RTSP中使用的方法及其分類目的地類的設(shè)定例。(基于不正當(dāng)?shù)目梢啥鹊念惙诸?有時(shí)通過惡意客戶的不正當(dāng)?shù)脑L問占有服務(wù)器的計(jì)算資源。 為避免該問題，在本實(shí)施例的負(fù)荷控制裝置中，也可以并用檢測懷疑不正當(dāng)訪問的通信的侵入檢測功能，把判定為不正當(dāng)訪問的可能性高的請求分類到低優(yōu)先的類中。進(jìn)而，也能夠與“基于客戶機(jī)識別信息的類分類”聯(lián)合，把判定為發(fā)送不正當(dāng)訪問的可能性高的通信的請求在一定期間非優(yōu)先化。亦即，I)在負(fù)荷控制裝置中，評價(jià)接收中的通信是不正當(dāng)訪問的可能性。2)在一定期間記錄判定為不正當(dāng)訪問的可能性高的通信的發(fā)送源識別信息。3)當(dāng)接收請求時(shí)，判定該客戶機(jī)的識別信息與記錄的識別信息是否一致。4)在一致的場合，分類到低優(yōu)先的類中。另外，侵入檢測功能，也可以通過連接負(fù)荷控制裝置和已有的侵入檢測裝置(IDS Intrusion Diction System)等,作為負(fù)荷控制裝置的外部裝置來實(shí)現(xiàn)。在該場合，從侵入檢測裝置向負(fù)荷控制裝置作為警報(bào)發(fā)送關(guān)于不正當(dāng)訪問的信息，亦即不正當(dāng)訪問的種類或者成為發(fā)送源的客戶機(jī)識別信息。在負(fù)荷控制裝置中根據(jù)警報(bào)實(shí)施請求的優(yōu)先控制。這樣，通過把懷疑不正當(dāng)訪問的請求分類到低優(yōu)先類中，在服務(wù)器擁擠時(shí)，能夠從正常的可能性高的請求優(yōu)先地進(jìn)行處理。作為限制同樣的不正當(dāng)訪問的裝置有侵入防御系統(tǒng)。在侵入防御系統(tǒng)中，立即廢棄被判定為不正當(dāng)訪問的通信。因此，由于把正常的請求誤判定為不正當(dāng)，有誤限制正常請求的誤限制的問題。但是，在本發(fā)明中，因?yàn)橹灰?wù)器不擁擠，懷疑不正當(dāng)?shù)恼埱笠苍诜?wù)器上處理，所以能夠緩和侵入防御系統(tǒng)中的誤限制的問題。在第一實(shí)施例中，靜態(tài)給予應(yīng)答等待請求數(shù)的閾值。但是，如上所述，通過人工的應(yīng)答等待請求數(shù)的閾值設(shè)定，會給負(fù)荷管理裝置3的管理者施加大的負(fù)擔(dān)。因此，擴(kuò)展第一實(shí)施例，使a)能夠最大限度地引出服務(wù)器4的處理性能，而且b)為把應(yīng)答時(shí)間納入允許范圍，可以動(dòng)態(tài)設(shè)定應(yīng)答等待請求數(shù)的閾值。列舉用于自動(dòng)調(diào)整應(yīng)答等待請求數(shù)的閾值的實(shí)施例。(自動(dòng)調(diào)整的實(shí)施例I)定期測定緩沖器中等待的(平均)請求數(shù)N以及從負(fù)荷控制裝置3向服務(wù)器4發(fā)送請求到收到應(yīng)答的(平均)應(yīng)答時(shí)間T。另外，作為對于N、T的閾值，定為LN、LT。此時(shí)如果N < LN，則因?yàn)檎埱罅可?，視之為?yīng)答等待請求數(shù)未達(dá)到其閾值。另外，如果T < LT,則視之為返回了良好的應(yīng)答。所以， 如果T > LT,則使減小應(yīng)答等待請求數(shù)的閾值。
T < LT
如果-N ^ LN,則使應(yīng)答等待請求數(shù)的閾值增加。如果-N < LN,則使應(yīng)答等待請求數(shù)的閾值不變。(自動(dòng)調(diào)整的實(shí)施例2)定期測定緩沖器中等待的(平均)請求數(shù)N以及從負(fù)荷控制裝置3向服務(wù)器4返回請求到收到應(yīng)答的應(yīng)答時(shí)間T。另外，作為對于N、T的閾值，定為LN、LT。進(jìn)而，假定把成為T > LT的請求的比例作為r。此時(shí)使用常數(shù)k(0彡k彡I)， 如果r ^ k,則使應(yīng)答等待請求數(shù)的閾值減小。
r < k如果-N ^ LN,則使應(yīng)答等待請求數(shù)的閾值增加。如果-N < LN,則使應(yīng)答等待請求數(shù)的閾值不變。(自動(dòng)調(diào)整的實(shí)施例3)定期測定緩沖器中等待的(平均)請求數(shù)N以及服務(wù)器4的使用率U。另外，作為對于N、U的閾值，定為LN、LU。 如果U > LU，則使應(yīng)答等待請求數(shù)的閾值減小。
U < LU如果-N ^ LN,則使應(yīng)答等待請求數(shù)的閾值增加。如果-N < LN,則使應(yīng)答等待請求數(shù)的閾值不變。不僅CPU使用率，也可以監(jiān)視存儲器使用率、帶寬、并列度，把其最大值作為U。(自動(dòng)調(diào)整的實(shí)施例4)定期測定緩沖器中等待的(平均)請求數(shù)N以及作為服務(wù)器4每單位時(shí)間能夠處理的請求數(shù)的通過量T。另外，設(shè)現(xiàn)在的應(yīng)答等待請求數(shù)的閾值為R。另外，做成對于每一個(gè)應(yīng)答等待請求數(shù)的閾值R能夠記錄通過量。這里，把對于應(yīng)答等待請求數(shù)的閾值R的通過量記為T[R]。另外，作為對于緩沖器中的請求數(shù)N的閾值，定為LN。此時(shí)，根據(jù)測定的N以及T，實(shí)施以下處理。I)如果N < LN，則意味著應(yīng)答等待請求數(shù)未達(dá)到閾值，所以不更新應(yīng)答等待請求數(shù)的閾值而結(jié)束。如果N彡LN，則實(shí)施2)。2)用T更新對于現(xiàn)在的應(yīng)答等待請求數(shù)的閾值的通過量T[R]，接著實(shí)施3)。3)比較對于現(xiàn)在的應(yīng)答等待請求數(shù)的閾值R的通過量T[R]、和閾值更小的場合的通過量 T[R’ ] (R，< R)。A)在T[R]彡klXT[R’]的場合意味著通過增加應(yīng)答等待請求數(shù)的閾值，能夠提高通過量。所以會進(jìn)一步使應(yīng)答等待請求數(shù)的閾值增加。這里，kl是常數(shù)，kl ^ I. O。B)在T[R] ( k2XT[R’]的場合意味著通過增加應(yīng)答等待請求數(shù)的閾值，減少了通過量。所以，使應(yīng)答等待請求數(shù)的閾值減小。這里，k2是常數(shù)，kl < 1.0。C)在上述以外的場合，使應(yīng)答等待請求數(shù)的閾值不變。在本發(fā)明中，根據(jù)緩沖器中的等待請求數(shù)，判定應(yīng)答等待請求數(shù)是否達(dá)到其閾值。然后，在判定應(yīng)答等待請求數(shù)達(dá)到其閾值的場合，判定是否應(yīng)該使應(yīng)答等待請求數(shù)的閾值增加。由此，在給服務(wù)器4沒有施加足夠的負(fù)荷的狀態(tài)下，消除了應(yīng)答等待請求數(shù)的閾值無限制增加的問題。另外，在上述實(shí)施例中，在N < LN即應(yīng)答等待請求數(shù)未達(dá)到其閾值、的場合，保持應(yīng)答等待請求數(shù)的閾值不變。但是，在N < LN的場合，也可以使應(yīng)答等待請求數(shù)的閾值減小。在上述的實(shí)施例中，決定好應(yīng)答等待請求數(shù)的閾值的最大值和最小值，在修正后的應(yīng)答等待請求數(shù)的閾值成為其范圍外的場合，也可以不進(jìn)行其修正。(第二實(shí)施形態(tài))下面，作為第二實(shí)施形態(tài)，表示作為收發(fā)請求以及應(yīng)答的協(xié)議，使用在因特網(wǎng)中廣泛使用的TCP/IP(傳輸控制協(xié)議/因特網(wǎng)協(xié)議)的場合。圖10是表示本發(fā)明的第二實(shí)施形態(tài)的框圖。本實(shí)施形態(tài)，由發(fā)行請求的客戶機(jī)1-1 1-n、返回與請求對應(yīng)的應(yīng)答的服務(wù)器4、以及居中調(diào)停請求 應(yīng)答的負(fù)荷控制裝置3組成。負(fù)荷控制裝 置3也可以擴(kuò)展安裝反向Proxy、Web加速器、Firewall、負(fù)荷分散系統(tǒng)等的現(xiàn)有技術(shù)。本實(shí)施形態(tài)的負(fù)荷控制系統(tǒng)由下面的5個(gè)功能塊構(gòu)成。 請求接收部30 請求發(fā)送部32 應(yīng)答接收部34 應(yīng)答發(fā)送部33 調(diào)度部31請求接收部30,向調(diào)度部31發(fā)送從客戶機(jī)1-1 1-n接收到的請求。圖11表示請求接收部30的處理過程。首先，當(dāng)新確立來自客戶機(jī)1-1 1-n的TCP連接時(shí)(S30)，在客戶機(jī)1-1 1-n和負(fù)荷控制裝置3之間生成用于收發(fā)應(yīng)答的套接字(S31)。此時(shí)，在生成的套接字中，分配唯一識別套接字的ID (套接字ID)。接著，選擇一個(gè)客戶機(jī)側(cè)套接字(S32)。檢查該客戶機(jī)側(cè)套接字(S33)。檢查的結(jié)果，在套接字中包含新的請求的場合(S34)，進(jìn)行從各套接字讀出請求的請求接收處理(S35)。每次讀出請求時(shí)，給各請求分配唯一識別請求的請求ID。接著，為維持請求和客戶機(jī)側(cè)的套接字的對應(yīng)關(guān)系，在圖12表示的請求表中，登記請求ID以及套接字ID的組(S36)。最后，把接收到的請求向調(diào)度部31發(fā)送(S37)。另外，檢查客戶機(jī)側(cè)套接字的結(jié)果(S33)，在該套接字中不包含新的請求的場合(S34)，選擇下一個(gè)客戶機(jī)側(cè)套接字(S32)，重復(fù)處理(S33 S37) (S38)。進(jìn)而，與請求的讀出并行，檢查是否由于超時(shí)等的原因TCP連接被切斷(S39)。在連接被切斷的場合，廢棄該套接字(S40)。請求發(fā)送部32，進(jìn)行用于從負(fù)荷控制裝置3向服務(wù)器4發(fā)送請求的套接字的管理、以及請求的發(fā)送處理。圖13表示請求發(fā)送部32的處理過程。請求發(fā)送部32，當(dāng)從調(diào)度部31接收到新的發(fā)送請求時(shí)(S50)，參照圖14表示的服務(wù)器側(cè)套接字表，檢查在和發(fā)送目的地的服務(wù)器4之間是否存在空閑狀態(tài)的套接字(S51)。這里，所謂空閑狀態(tài)的套接字，指在負(fù)荷控制裝置3和發(fā)送目的地的服務(wù)器4之間已確立TCP連接、而且迄今與對于服務(wù)器4發(fā)送的請求對應(yīng)的應(yīng)答已經(jīng)全部接收了的套接字。在檢測到空閑狀態(tài)的套接字的場合(S52)，把該套接字作為請求發(fā)送用套接字選擇。在空閑狀態(tài)的套接字不存在的場合(S52)，新確立和發(fā)送目的地的服務(wù)器4的TCP連接，生成請求發(fā)送用套接字(S53)。此時(shí)，給套接字分配唯一的ID。然后，在服務(wù)器側(cè)套接字表中登記生成的套接字的ID(S54)，將其狀態(tài)設(shè)為空閑狀態(tài)。當(dāng)選擇空閑狀態(tài)的套接字時(shí)，接著，在服務(wù)器側(cè)套接字表中登記該請求ID (S56)。此時(shí)，把套接字的狀態(tài)從空閑變更為忙(S55)。最后,對于服務(wù)器4發(fā)送請求(S57)。另外，請求發(fā)送部32，經(jīng)常監(jiān)視并檢測有無由于超時(shí)等被切斷的TCP連接(S58)。在檢測到被切斷的TCP連接的場合(S59)，廢棄對應(yīng)的套接字(S60)。從服務(wù)器側(cè)套接字表中刪除(SGl)0像本實(shí)施形態(tài)這樣，本發(fā)明，在請求發(fā)送時(shí)，不拘泥于其發(fā)送源客戶機(jī)，將再使用空閑狀態(tài)的套接字(連接集約)。通過連接集約，在負(fù)荷控制裝置3側(cè)，能夠進(jìn)行調(diào)整以使在服務(wù)器4和負(fù)荷控制裝置3之間的TCP連接數(shù)不超過客戶機(jī)數(shù)。因此，服務(wù)器側(cè)套接字?jǐn)?shù)不會超過應(yīng)答等待請求數(shù)的閾值。所以，如果應(yīng)答等待請求 數(shù)的閾值比TCP連接數(shù)的限制小，則請求發(fā)送不會由于TCP連接數(shù)的限制而被封鎖在圖13的實(shí)施例中，把一個(gè)套接字能夠同時(shí)向服務(wù)器4發(fā)送的請求數(shù)取為I。但是，也可以不等待應(yīng)答的返回，用一個(gè)套接字連續(xù)發(fā)送多個(gè)請求。通過從一個(gè)套接字連續(xù)向服務(wù)器4發(fā)送多個(gè)請求，能夠減輕套接字的生成或者廢棄的開銷。圖15表示應(yīng)答接收部34的處理過程。應(yīng)答接收部34接收從服務(wù)器4返回的應(yīng)答(S70)。接著，參照服務(wù)器側(cè)套接字表，選擇接收到應(yīng)答的服務(wù)器側(cè)套接字(S71)。接著，讀入應(yīng)答(S72)，從服務(wù)器側(cè)套接字表的ID取得對應(yīng)的請求ID(S73)。然后，作為接收到的應(yīng)答ID，分配和對應(yīng)的請求相同的ID。接著，向調(diào)度部31、應(yīng)答發(fā)送部33發(fā)送應(yīng)答(S74)。最后，為了能夠從該套接字發(fā)送下一請求，把套接字的狀態(tài)從忙變更為空閑(S75)。圖16表示應(yīng)答發(fā)送部33的處理過程。在應(yīng)答發(fā)送部33中，當(dāng)接收到應(yīng)答時(shí)(S80)，根據(jù)該應(yīng)答ID (和請求ID —致)參照請求表，取得和應(yīng)該發(fā)送應(yīng)答的客戶機(jī)連接的客戶機(jī)側(cè)套接字ID(SSl)，選擇客戶機(jī)側(cè)套接字。接著，通過在套接字中寫入應(yīng)答向客戶機(jī)返回應(yīng)答(S82)。在調(diào)度部31中，和第一實(shí)施形態(tài)相同，在緩沖器中緩沖存儲接收到的請求。然后，在應(yīng)答等待請求數(shù)降低到低于閾值的場合，選擇在緩沖器中存儲的請求，向服務(wù)器4發(fā)送。圖17表示調(diào)度部31的處理過程。在接收到請求的場合，首先在緩沖器中存儲請求(S90)。接著，判定在緩沖器中是否存在發(fā)送等待請求(S91)。在存在發(fā)送等待請求的場合，判定現(xiàn)在的應(yīng)答等待請求數(shù)是否超過其閾值(S92)。在閾值以上的場合結(jié)束該處理。在發(fā)送中請求數(shù)不到閾值的場合，使應(yīng)答等待請求數(shù)增加I (S93)。接著，從緩沖器中取出一個(gè)請求，對于請求發(fā)送部32發(fā)送(S94)。另一方面，在接收到應(yīng)答的場合，把應(yīng)答等待請求數(shù)減I (S95)，使能夠發(fā)送下一請求，其后的處理，和請求接收時(shí)相同，執(zhí)行圖17的步驟S91“緩沖器中存在請求？ ”及以下步驟。在上述的實(shí)施例中，把服務(wù)器臺數(shù)設(shè)為I臺，但是也可以使用多個(gè)服務(wù)器。在使用多個(gè)服務(wù)器的場合，按照服務(wù)器臺數(shù)復(fù)制調(diào)度部31、應(yīng)答發(fā)送部33、應(yīng)答接收部34。然后，在請求接收部30中，只要遵照送達(dá)地向各服務(wù)器用的各處理部分配請求即可。為了表示本發(fā)明的效果，在PC (個(gè)人計(jì)算機(jī))上安裝本發(fā)明的負(fù)荷控制裝置3，進(jìn)行實(shí)驗(yàn)性評價(jià)。評價(jià)，是通過在有本發(fā)明的負(fù)荷控制裝置3的場合和沒有的場合比較使從客戶機(jī)1-1 1-n向服務(wù)器4輸入的請求率(每秒請求數(shù)rps)變化了的場合的Web服務(wù)器的通過量(rps)。
圖18表示實(shí)驗(yàn)的結(jié)構(gòu)。如圖18所示，客戶機(jī)1-1 1-n和服務(wù)器4，通過L2開關(guān)5以及負(fù)荷控制裝置3進(jìn)行通信。在服務(wù)器4和負(fù)荷控制裝置3之間以及負(fù)荷控制裝置3和L2開關(guān)5之間的網(wǎng)絡(luò)(省略圖示)的帶寬為lGbps。另一方面，在客戶機(jī)1-1 1-n和L2開關(guān)5之間的網(wǎng)絡(luò)(省略圖示)的帶寬為100Mbps。這里，圖19表示服務(wù)器4以及負(fù)荷控制裝置3的結(jié)構(gòu)。在本實(shí)驗(yàn)中，把負(fù)荷控制裝置3的應(yīng)答等待請求數(shù)的閾值固定為“10”。為和現(xiàn)有的負(fù)荷控制方法比較，設(shè)定可同時(shí)連接服務(wù)器4的TCP連接數(shù)的上限為150。另外，把客戶機(jī)1-1 1-n從發(fā)送到接收請求的超時(shí)時(shí)間設(shè)定為10秒。當(dāng)達(dá)到超時(shí)時(shí)，客戶機(jī)1-1 1-n切斷TCP連接，撤消該請求。圖20表示實(shí)驗(yàn)結(jié)果。圖20橫軸為輸入請求率,縱軸為通過量。圖20表示對于來自客戶機(jī)1-1 1-n的輸入請求率(rps)的服務(wù)器4的通 過量(rps)的變化。圖20中的“本發(fā)明”表示有負(fù)荷控制裝置3的場合的結(jié)果。“現(xiàn)有方法”表示不通過負(fù)荷控制裝置3連接服務(wù)器4和客戶機(jī)1-1 1-n的場合的結(jié)果。從圖20可知，如果輸入請求率在IOOrps以下，則與負(fù)荷控制裝置3的有無無關(guān)，服務(wù)器4的通過量與輸入請求率成比例增加。但是，當(dāng)輸入請求率超過IOOrps時(shí)，在沒有負(fù)荷控制裝置3的場合，通過量顯著降低。例如，輸入率為200rps時(shí)的通過量為尖峰時(shí)的約 60%。另一方面，當(dāng)使用本發(fā)明的負(fù)荷控制裝置3時(shí)，即使輸入請求率從IOOrps增加，其通過量也能夠維持尖峰時(shí)的90%以上。以上的結(jié)果可以說證明了本發(fā)明的負(fù)荷控制裝置3的有效性。下面表示通過自動(dòng)調(diào)整應(yīng)答等待請求數(shù)的閾值而產(chǎn)生的效果。在本評價(jià)中使用和圖18同樣的結(jié)構(gòu)。另外，圖21表示本評價(jià)中的服務(wù)器4以及負(fù)荷控制裝置3的細(xì)節(jié)。在本評價(jià)中，作為Web應(yīng)用，設(shè)想在線購物，使用基準(zhǔn)軟件SPEC WEB2005Ecommerce (例如參照Http://www. spec, org)。在該Web應(yīng)用中，到結(jié)束購物需要大約13頁。另外,在客戶PC上執(zhí)行模擬現(xiàn)實(shí)的客戶的動(dòng)作的程序。在客戶機(jī)程序中，自動(dòng)訪問Web服務(wù)器，嘗試對話的執(zhí)行。此時(shí)，客戶機(jī)程序的動(dòng)作，和現(xiàn)實(shí)的客戶相同，要考慮從取得一個(gè)頁到移動(dòng)到下一頁的思考時(shí)間、讀入頁的超時(shí)。在超時(shí)的場合，嘗試再次取得該頁。另外，以一定的概率向前面的頁返回，或者對話中途中斷。在本評價(jià)中，首先向負(fù)荷控制裝置3發(fā)送高于服務(wù)器4的最大處理性能的量的請求。接著，在靜態(tài)設(shè)定應(yīng)答等待請求數(shù)的閾值的場合、和根據(jù)本發(fā)明進(jìn)行自動(dòng)調(diào)整的場合，測定比較服務(wù)器4中作為單位時(shí)間處理的請求數(shù)的通過量。首先，評價(jià)靜態(tài)設(shè)定應(yīng)答等待請求數(shù)的閾值的場合。圖22表示其評價(jià)結(jié)果。圖22的圖表，表示對于應(yīng)答等待請求數(shù)的閾值的設(shè)定值的通過量的變化。亦即圖22的橫軸是應(yīng)答等待請求數(shù)的閾值的設(shè)定值，縱軸是服務(wù)器4的通過量(rps)。從圖22的圖表可知，服務(wù)器4的通過量在應(yīng)答等待請求數(shù)的閾值是“2”的場合，是671rps為最大，伴隨應(yīng)答等待請求數(shù)的增加慢慢降低。從該結(jié)果可知，假定要希望把通過量維持在最大值的97%以上，就需要把應(yīng)答等待請求數(shù)的閾值設(shè)定在“2” “6”的范圍內(nèi)。下面，表示使用上述的(自動(dòng)調(diào)整的實(shí)施例4)，基于本發(fā)明自動(dòng)調(diào)整了應(yīng)答等待請求數(shù)的閾值的結(jié)果。另外，為表示基于本發(fā)明的閾值的自動(dòng)調(diào)整法的有效性，一并表示將在非專利文獻(xiàn)I中表示的頁單位的并列度自動(dòng)調(diào)整法應(yīng)用到了在應(yīng)答等待請求數(shù)的閾值的控制中的場合的結(jié)果。另外，非專利文獻(xiàn)I中表示的頁單位的并列度自動(dòng)調(diào)整法如下。首先，定期測定通過量，決定是增加還是減小并列度。這里，把第i次的測定中的通過量設(shè)為Ti。另外，把第i次的測定時(shí)的并列度設(shè)為Ci。此時(shí)， 如果Ci > Ci-I而且Ti ^ Ti-I，則使并列度增加。 如果Ci > Ci-I而且Ti < Ti-I，則使并列度減小。 如果Ci < Ci-I而且Ti彡Ti-I，則使并列度減小。 如果Ci < Ci-I而且Ti < Ti-I，則使并列度增加。亦即，和前次的測定結(jié)果比較，如果通過量提高，則進(jìn)行和前次相同的操作(并列 度的增加或者減小)。反之，如果通過量減小，則施行和前次相反的操作。圖23的圖表表示應(yīng)答等待請求數(shù)的閾值的時(shí)間的變化。圖23的橫軸是時(shí)間(秒)，縱軸是應(yīng)答等待請求數(shù)的閾值。在圖23中，在基于本發(fā)明的自動(dòng)調(diào)整法中，應(yīng)答等待請求數(shù)的閾值固定到了閾值為“2” “6”之間的時(shí)間，達(dá)到了觀察時(shí)間的96.9%。此外，基于本發(fā)明自動(dòng)調(diào)整的場合的平均通過量為660rps，這達(dá)到了靜態(tài)設(shè)定的場合的最大通過量的98%。另一方面，從圖23可知，在根據(jù)非專利文獻(xiàn)I的方法中，應(yīng)答等待請求數(shù)的閾值異常增加。在通過非專利文獻(xiàn)I的方法中產(chǎn)生這種異常增加的原因如下。(I)在基于非專利文獻(xiàn)I的方法中，沒有判定現(xiàn)在的應(yīng)答等待請求數(shù)是否達(dá)到其閾值的單元。所以，當(dāng)向服務(wù)器的輸入請求率慢慢增加時(shí)，在達(dá)到應(yīng)答等待請求數(shù)的閾值前有其閾值無限制增加這樣的問題。與此相對，在本發(fā)明中，只要隊(duì)列中的請求數(shù)未達(dá)到足夠的數(shù)，就不使應(yīng)答等待請求數(shù)的閾值增加，這樣就避免了該問題。(2)在基于非專利文獻(xiàn)I的方法中，應(yīng)答等待請求數(shù)的閾值的增減，從上次和此次的通過量的測量結(jié)果的比較這樣的局部的通過量的變化來決定。因此，在通過量暫時(shí)大幅降低后慢慢恢復(fù)的場合等，會產(chǎn)生盡管通過量長期不能增大而應(yīng)答等待請求數(shù)的閾值卻無限制增加(或者減小)這樣的問題。與此相對，在本發(fā)明的自動(dòng)調(diào)整的實(shí)施例4中，通過對于每一個(gè)應(yīng)答等待請求數(shù)的閾值記錄比較通過量，就設(shè)計(jì)成了只要通過量不增加就不使閾值增加。另外，在自動(dòng)調(diào)整的實(shí)施例I 3中，通過給應(yīng)答時(shí)間設(shè)定閾值，就避免了應(yīng)答等待請求數(shù)的閾值無限制增加的問題。接著，作為基于本發(fā)明的請求的優(yōu)先控制的效果的一例，表示基于對話的進(jìn)行狀況的類分類的評價(jià)結(jié)果。亦即，根據(jù)是否包含有效的對話ID，把請求分類。然后，使用Priority Queuing,優(yōu)先在服務(wù)器中處理包含有效的對話ID的請求。本評價(jià)中使用和圖18同樣的結(jié)構(gòu)。另外，本評價(jià)中的服務(wù)器4以及負(fù)荷控制裝置3的細(xì)節(jié)和圖21相同。但是，負(fù)荷控制裝置的應(yīng)答等待請求數(shù)的閾值靜態(tài)地設(shè)定為10。以以上的條件為基礎(chǔ)，在有負(fù)荷控制裝置的場合和沒有的場合下比較使對于Web服務(wù)器上試驗(yàn)對話處理的客戶機(jī)數(shù)變化時(shí)的、Web服務(wù)器在單位時(shí)間能夠結(jié)束的對話數(shù)(以下稱對話通過量)。圖24表示實(shí)驗(yàn)結(jié)果。圖24的縱軸是對話通過量，橫軸表示客戶機(jī)數(shù)。如圖24所示，在到達(dá)400客戶機(jī)之前，與負(fù)荷控制裝置的有無無關(guān)，對于客戶機(jī)數(shù)，服務(wù)器的對話通過量成比例地增加。但是，當(dāng)超過400客戶機(jī)時(shí)，服務(wù)器變得過負(fù)荷，在客戶機(jī)之間就要競爭服務(wù)器資源。其結(jié)果，在沒有負(fù)荷控制裝置的場合，在各客戶機(jī)中相等地發(fā)生超時(shí)或者中途中斷，對話通過量轉(zhuǎn)而降低。然后，在800客戶機(jī)處，對話就變得完全不結(jié)束。與此相對，在本實(shí)施例的負(fù)荷控制裝置中，更優(yōu)先地處理正進(jìn)行的對話。其結(jié)果，即使在Web服務(wù)器成為過負(fù)荷的狀態(tài)下也一直最大地維持對話通過量。以上的結(jié)果，證明了根據(jù)本實(shí)施例的負(fù)荷控制裝置的優(yōu)先控制的效果。可以說以上的結(jié)果表示本發(fā)明的有效性。本實(shí)施例，通過在通用的信息處理裝置中安裝，能夠在該信息處理裝置中作為使實(shí)現(xiàn)與在本實(shí)施例中說明的負(fù)荷控制裝置3相應(yīng)的功能的程序來實(shí)施。該程序，被記錄在記錄介質(zhì)上，并被安裝在通用的信息處理裝置中，或者通過通信線路被安裝在通用的信息處理裝置中，由此，就能夠把該通用的信息處理裝置作為與在本 實(shí)施例中說明的負(fù)荷控制裝置3相應(yīng)的裝置。另外，本實(shí)施例的程序，不僅包含通過通用的信息處理裝置可直接執(zhí)行的程序，而且也包含通過安裝在硬盤等上可執(zhí)行的程序。另外，還包含壓縮或者加密過的程序。根據(jù)本發(fā)明，能夠避免接收過剩請求時(shí)服務(wù)器的性能降低，另外，因?yàn)檫€能夠自動(dòng)化設(shè)定為適當(dāng)控制的閾值，所以對于裝置(網(wǎng)絡(luò))管理者以及網(wǎng)絡(luò) 用戶的雙方來說，都能提聞便利性。
權(quán)利要求
1.ー種負(fù)荷控制裝置⑶，其被配置在客戶機(jī)(1-1.....I-η)和服務(wù)器⑷之間，向所述服務(wù)器(4)發(fā)送從所述客戶機(jī)(1-1.....I-η)接收到的請求，向所述客戶機(jī)(1-1.....I-η)發(fā)送對于該請求從所述服務(wù)器(4)返回的應(yīng)答，其特征在干， 具有限制已向所述服務(wù)器(4)發(fā)送完畢但是未從所述服務(wù)器(4)返回應(yīng)答的應(yīng)答等待請求的數(shù)的單元， 該進(jìn)行限制的単元具有 若應(yīng)答等待請求數(shù)達(dá)到了閾值，則臨時(shí)存儲接收到的請求的緩沖器； 在應(yīng)答等待請求數(shù)下降到低于閾值前，使來自所述緩沖器的請求的發(fā)送等待的単元；在應(yīng)答等待請求數(shù)不足閾值時(shí)，從所述緩沖器中選擇取出ー個(gè)請求，在把應(yīng)答等待請求數(shù)加I后，將該請求發(fā)送給所述服務(wù)器(4)的単元；以及 把從所述服務(wù)器(4)接收到的應(yīng)答返回給發(fā)送了該應(yīng)答的請求的客戶機(jī)，并使應(yīng)答等待請求數(shù)減I的單元。
2.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述閾值是比I大的值。
3.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)， 具有以下単元 監(jiān)視所述服務(wù)器(4)的執(zhí)行狀況的單元；和 根據(jù)該進(jìn)行監(jiān)視的単元的監(jiān)視結(jié)果在對于所述服務(wù)器(4)的請求的應(yīng)答時(shí)間在允許范圍內(nèi)時(shí)增大所述應(yīng)答等待請求數(shù)的閾值、而在該應(yīng)答時(shí)間超過允許范圍的場合減小所述應(yīng)答等待請求數(shù)的閾值的単元。
4.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)， 具有以下単元 監(jiān)視所述服務(wù)器(4)的執(zhí)行狀況的單元； 根據(jù)該進(jìn)行監(jiān)視的単元的監(jiān)視結(jié)果對于應(yīng)答等待請求數(shù)的每ー閾值測定在每單位時(shí)間服務(wù)器(4)已處理的請求數(shù)即吞吐量的単元；和 在對于現(xiàn)在的閾值的通過量高于對于比現(xiàn)在的閾值小的閾值的通過量的場合增大閾值，而在對于現(xiàn)在的閾值的通過量低于對于比現(xiàn)在的閾值小的閾值的通過量的場合減小閾值的單元。
5.根據(jù)權(quán)利要求3或4所述的負(fù)荷控制裝置(3)， 具有以下単元 判定應(yīng)答等待請求數(shù)是否達(dá)到了其閾值的単元；和 在達(dá)到了閾值的場合判定是否増大或者減小閾值的單元。
6.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)， 具有下述的單元，亦即，為了使所述服務(wù)器(4)和自己(3)之間的TCP連接的同時(shí)連接數(shù)成為所述應(yīng)答等待請求數(shù)的閾值以下，集約自己(3)和所述客戶機(jī)(1-1.....I-η)之間的TCP連接的單元。
7.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述緩沖器具有根據(jù)發(fā)送源客戶機(jī)(1-1.....I-η)的識別信息優(yōu)先控制請求的単元。
8.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中，所述緩沖器具有根據(jù)是否在請求中的特定的位置或者范圍內(nèi)包含特定的模式來優(yōu)先控制請求的単元。
9.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述緩沖器具有根據(jù)請求中的特定的變量是否比預(yù)先設(shè)定的閾值大來優(yōu)先控制請求的單元。
10.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述緩沖器具有根據(jù)請求是否已被加密來優(yōu)先控制請求的単元。
11.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述緩沖器具有對于存儲了規(guī)定時(shí)間以上的請求通知忙消息的単元。
12.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述服務(wù)器(4)是Web服務(wù)器， 所述緩沖器具有根據(jù)請求的頁顯示的顯示優(yōu)先級來優(yōu)先控制請求的単元。
13.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述請求通過TCP連接從客戶機(jī)(1-1.....I-η)向負(fù)荷控制裝置(3)發(fā)送， 所述緩沖器具有下述的單元，亦即，根據(jù)在客戶機(jī)和負(fù)荷控制裝置之間連接的其他的TCP連接的有無或者TCP連接的數(shù)以及該請求是否是TCP連接的最初的請求來優(yōu)先控制請求的單元。
14.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 具有在對應(yīng)答指示了瀏覽器應(yīng)該自動(dòng)取得的頁構(gòu)成要素的URL的場合臨時(shí)存儲應(yīng)答發(fā)送目的地的識別信息和該URL的組的單元， 所述緩沖器具有根據(jù)請求的發(fā)送源的識別信息和URL的組與臨時(shí)存儲的應(yīng)答發(fā)送目的地的識別信息和URL的組是否一致來優(yōu)先控制請求的単元。
15.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 具有根據(jù)所述請求屬于的對話的進(jìn)行狀況來優(yōu)先控制請求的単元。
16.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 具有以下単元 在一定期間超高速緩沖存儲在所述服務(wù)器(4)中處理的請求屬于的對話的對話識別信息的単元；和 根據(jù)是否具有超高速緩沖存儲的對話識別信息來優(yōu)先控制請求的単元。
17.根據(jù)權(quán)利要求I所述的負(fù)荷控制裝置(3)，其中， 所述緩沖器具有根據(jù)從客戶機(jī)(1-1.....I-η)發(fā)送的通信的非法訪問的可疑度來優(yōu)先控制請求的単元。
18.ー種負(fù)荷控制方法，其由負(fù)荷控制裝置(3)執(zhí)行，所述負(fù)荷控制裝置(3)被配置在客戶機(jī)(1-1.....I-η)和服務(wù)器(4)之間，向所述服務(wù)器(4)發(fā)送從所述客戶機(jī)(1-1.....I-η)接收到的請求，向所述客戶機(jī)(1-1.....I-η)發(fā)送對于該請求從所述服務(wù)器⑷返回的應(yīng)答，其特征在于， 具有限制已向所述服務(wù)器發(fā)送完畢但是未從所述服務(wù)器返回應(yīng)答的應(yīng)答等待請求的數(shù)的步驟(S10-S14，S20-S26)， 該進(jìn)行限制的步驟具有以下步驟若應(yīng)答等待請求數(shù)達(dá)到了閾值，則在緩沖器中臨時(shí)存儲接收到的請求的步驟(S10，Sn)； 在應(yīng)答等待請求數(shù)下降到低于閾值前使來自所述緩沖器的請求的發(fā)送等待的步驟(S11-S14, S23-S26)； 在應(yīng)答等待請求數(shù)不足閾值時(shí)，從所述緩沖器中選擇取出ー個(gè)請求，在使應(yīng)答等待請求數(shù)加I后，將該請求發(fā)送給所述服務(wù)器⑷的步驟(S12-S14);以及 把從所述服務(wù)器(4)接收到的應(yīng)答返回給發(fā)送了該應(yīng)答的請求的客戶機(jī)，并使應(yīng)答等待請求數(shù)減I的步驟(S20、S21)。
19.根據(jù)權(quán)利要求18所述的負(fù)荷控制方法，其中， 所述閾值是比I大的值。
20.根據(jù)權(quán)利要求18所述的負(fù)荷控制方法，其中， 具有以下步驟 監(jiān)視所述服務(wù)器(4)的執(zhí)行狀況的步驟；和 根據(jù)所述進(jìn)行監(jiān)視的步驟的監(jiān)視結(jié)果在對于所述服務(wù)器的請求的應(yīng)答時(shí)間在允許范圍內(nèi)時(shí)增大所述應(yīng)答等待請求數(shù)的閾值，而在該應(yīng)答時(shí)間超過允許范圍的場合減小所述應(yīng)答等待請求數(shù)的閾值的步驟。
21.根據(jù)權(quán)利要求18所述的負(fù)荷控制方法，其中， 具有以下步驟 監(jiān)視所述服務(wù)器(4)的執(zhí)行狀況的步驟； 根據(jù)該進(jìn)行監(jiān)視的步驟的監(jiān)視結(jié)果對于應(yīng)答等待請求數(shù)的每ー閾值測定在每單位時(shí)間服務(wù)器已處理的請求數(shù)的通過量的步驟；和 在對于現(xiàn)在的閾值的通過量高于對于比現(xiàn)在的閾值小的閾值的通過量的場合增大閾值，而在對于現(xiàn)在的閾值的通過量低于對于比現(xiàn)在的閾值小的閾值的通過量的場合減小閾值的步驟。
22.根據(jù)權(quán)利要求20或者21所述的負(fù)荷控制方法，其中， 具有以下步驟 判定應(yīng)答等待請求數(shù)是否達(dá)到了其閾值的步驟；和 在達(dá)到了閾值的場合判定是否増大或者減小閾值的步驟。
23.根據(jù)權(quán)利要求18所述的負(fù)荷控制方法，其中， 具有下述的步驟，亦即，為了使所述服務(wù)器(4)和自己(3)之間的TCP連接的同時(shí)連接數(shù)成為所述應(yīng)答等待請求數(shù)的閾值以下，集約自己(3)和所述客戶機(jī)(1-1.....I-η)之間的TCP連接的步驟。
全文摘要
限制已向服務(wù)器(4)發(fā)送完畢但是未從服務(wù)器(4)返回應(yīng)答的應(yīng)答等待請求的數(shù)目。為進(jìn)行該限制，如果應(yīng)答等待請求數(shù)達(dá)到了閾值，則在緩沖器中臨時(shí)存儲接收到的請求，在應(yīng)答等待請求數(shù)降低到低于閾值前使來自緩沖器的請求的發(fā)送等待。另外，監(jiān)視服務(wù)器(4)的執(zhí)行狀況，在對于服務(wù)器(4)的請求的應(yīng)答時(shí)間在允許范圍內(nèi)時(shí)使所述閾值增大，在該應(yīng)答時(shí)間超過允許范圍的場合，使所述閾值減小。進(jìn)而，集約負(fù)荷控制裝置(3)和客戶機(jī)(1-1、...、1-n)之間的TCP連接，以使服務(wù)器(4)和負(fù)荷控制裝置(3)之間的連接的同時(shí)連接數(shù)成為應(yīng)答等待請求數(shù)的閾值以下。
文檔編號H04L29/06GK102684988SQ201110427918
公開日2012年9月19日 申請日期2007年4月25日 優(yōu)先權(quán)日2006年4月26日
發(fā)明者太田聰, 尾花和昭, 林經(jīng)正, 榑林亮介, 石田修 申請人:日本電信電話株式會社