(57)【要約】【課題】一組のサーバーのような処理ユニットの間で、サーバーの電力消費低下を許容するような仕方で、負荷を均衡化する方法およびシステムを提供する。【解決手段】負荷分散装置から処理ユニットに、処理ユニット・サービスの連続する要求を発送し、前記処理ユニットに発送される連続する要求はバッチ・サイズに等しいサイズをもつバッチを表し、要求のその後のバッチはそれぞれその後の処理ユニットに発送され、バッチを処理していない処理ユニットは低電力状態にはいる。これは一組の処理ユニットのエネルギー効率のよい動作を許容する。さらに、プロセスは、システム応答時間の変動に適応可能である。それにより、動作条件が指定するときにシステム応答時間が改善されうる。【選択図】図２
2011134330.tif 000002
【特許請求の範囲】
【請求項１】
負荷分散装置から処理ユニットに、処理ユニット・サービスの連続する要求を発送し、前記数の前記処理ユニットに発送される連続する要求はバッチ・サイズに等しいサイズをもつバッチを表し、要求のその後のバッチはそれぞれその後の処理ユニットに発送され、バッチを処理していない処理ユニットは低電力状態にはいり；
要求にサービスするためのシステム応答時間をモニタリングし；
前記システム応答時間が受け容れ可能な範囲から変動する場合に、その後の発送のためのバッチ・サイズを修正することを含む、
方法。
【請求項２】
前記処理ユニットがサーバーである、請求項１記載の方法。
【請求項３】
前記システム応答時間の前記受け容れ可能な範囲からの前記変動が、前記システム応答時間が上の閾値を超えることを含む、請求項１記載の方法。
【請求項４】
前記バッチ・サイズの修正が、前記バッチ・サイズを小さくすることを含む、請求項３記載の方法。
【請求項５】
前記バッチ・サイズが、前記システム応答時間が前記上の閾値を超えた量に相関した幅だけ小さくされる、請求項４記載の方法。
【請求項６】
前記システム応答時間の前記受け容れ可能な範囲からの前記変動が、前記システム応答時間が下の閾値を下回ることを含み、前記バッチ・サイズの修正が、前記バッチ・サイズを大きくすることを含む、請求項１記載の方法。
【請求項７】
コンピュータ・プログラム論理が記憶されたコンピュータ可読媒体を含むコンピュータ・プログラム・プロダクトであって、前記コンピュータ・プログラム論理は：
プロセッサに、負荷分散装置から処理ユニットに、処理ユニット・サービスの連続する要求を発送させ、前記数の前記処理ユニットに発送される連続する要求はバッチ・サイズに等しいサイズをもつバッチを表し、前記プロセッサにさらに、要求のその後のバッチをそれぞれその後の処理ユニットに発送させる論理であって、バッチを処理していない処理ユニットは低電力状態にはいる、論理と；
前記プロセッサに、要求にサービスするためのシステム応答時間をモニタリングさせる論理と；
前記プロセッサに、前記システム応答時間が受け容れ可能な範囲から変動する場合に、その後の発送のためのバッチ・サイズを修正させる論理とを含む、
コンピュータ・プログラム・プロダクト。
【請求項８】
前記処理ユニットがサーバーである、請求項７記載のコンピュータ・プログラム・プロダクト。
【請求項９】
前記システム応答時間の前記受け容れ可能な範囲からの前記変動が、前記システム応答時間が上の閾値を超えることを含む、請求項７記載のコンピュータ・プログラム・プロダクト。
【請求項１０】
前記バッチ・サイズの修正が、前記バッチ・サイズを小さくすることを含む、請求項９記載のコンピュータ・プログラム・プロダクト。
【請求項１１】
前記バッチ・サイズが、前記システム応答時間が前記上の閾値を超えた量に相関した幅だけ小さくされる、請求項１０記載のコンピュータ・プログラム・プロダクト。
【請求項１２】
前記システム応答時間の前記受け容れ可能な範囲からの前記変動が、前記システム応答時間が下の閾値を下回ることを含み、前記バッチ・サイズの修正が、前記バッチ・サイズを大きくすることを含む、請求項７記載のコンピュータ・プログラム・プロダクト。
【請求項１３】
負荷分散装置から処理ユニットに、処理ユニット・サービスの連続する要求を発送する手段であって、前記数の前記処理ユニットに発送される連続する要求はバッチ・サイズに等しいサイズをもつバッチを表し、要求のその後のバッチはそれぞれその後の処理ユニットに発送され、バッチを処理していない処理ユニットは低電力状態にはいる、手段と；
要求にサービスするためのシステム応答時間をモニタリングする手段と；
前記システム応答時間が受け容れ可能な範囲から変動する場合に、その後の発送のためのバッチ・サイズを修正する手段とを含む、
システム。
【請求項１４】
前記処理ユニットがサーバーである、請求項１３記載のシステム。
【請求項１５】
前記システム応答時間の前記受け容れ可能な範囲からの前記変動が、前記システム応答時間が上の閾値を超えることを含む、請求項１３記載のシステム。
【請求項１６】
前記バッチ・サイズの修正が、前記バッチ・サイズを小さくすることを含む、請求項１５記載のシステム。
【請求項１７】
前記バッチ・サイズが、前記システム応答時間が前記上の閾値を超えた量に相関した幅だけ小さくされる、請求項１６記載のシステム。
【請求項１８】
前記システム応答時間の前記受け容れ可能な範囲からの前記変動が、前記システム応答時間が下の閾値を下回ることを含み、前記バッチ・サイズの修正が、前記バッチ・サイズを大きくすることを含む、請求項１３記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー・クラスターにおけるエネルギー効率のよい負荷分散（load  balancing）のためのシステムおよび方法に関する。
【背景技術】
【０００２】
今日、データ・センターは大量のエネルギーを消費し、その傾向は高まりつつある。データ・センターにおいて、一群のサーバー（時にサーバー・クラスターと呼ばれる）または他のデータ処理ユニットの前に負荷分散装置（load  balancer）が置かれることがある。負荷分散装置は、はいってくる要求を複数のサーバーに分配する役割を担いうる。ランダムなまたはラウンドロビン式の負荷発送（load  dispatching）のような伝統的な方法は、はいってくる要求を、散らばった（dispersed）やり方でアクティブなサーバーに分配する。要求は、たとえばデータベースのコンテキストでは、データを求めるものであってもよいし、あるいはたとえば分散コンピューティングのコンテキストでは計算リソースを求めるものであってもよい。そうする際、個々の各処理ユニットについて、統計的にはそのユニットはかなりの時間にわたってアイドルであるとしても、負荷分散装置から要求が頻繁に到着する。結果として、処理ユニットが本来ならアイドルであってもよいようなときにもエネルギーが消費されうる。たとえば低電力状態への出入りの際、低電力状態にはいったり出たりするのは瞬間的には行われないので、遅延〔レイテンシ〕がある。この遅延期間の間は、その処理ユニットによって処理が行われないにも関わらず、厳密な低電力（または「スリープ」）状態で消費するよりも多くの電力を消費する。結果として、処理ユニットは、深い低電力状態にはいる機会がめったにないということになりうる。よって、データ・センターの電力消費が過剰になることがある。
【０００３】
スケーラビリティおよび高速応答時間を容易にするため、通常、要求、たとえばHTTP要求を処理するために多数の処理ユニット（時にクラスターと呼ばれる）が必要とされることがありうる。たとえばアクティブなサーバーの間での負荷分配を実行するために、負荷分散装置がサーバー・クラスターのフロント・エンドに位置されてもよい。負荷分散は、多くの型の処理ユニット、たとえばウェブ・サーバー、アプリケーション・サーバーおよびデータベース・サーバーについて使用されうる。
【０００４】
現代のデータ・センターでは、クラスター中のすべての処理ユニットが常時アクティブでないこともある。はいってくるトラフィックがヘビーになるときに、より多くの処理ユニットが持ち込まれてもよく、トラフィックが軽いときには電力節約のためにいくつかの処理ユニットはシャットダウンされる。アクティブな処理ユニットにとっては、目標利用率は通例、100%よりずっと低い。良好な応答時間を提供し、突然のバースト的な要求のための容量〔キャパシティ〕の余地をリザーブしておくためである。目標利用率60%では、処理ユニットは40%の時間はアイドルである。しかしながら、アイドル時間を時間的にどのように分配しうるかは、処理ユニットのエネルギー効率に大きな影響をもつ。
【０００５】
アクティブな処理ユニットの間ではいってくる要求を分配するために使われるさまざまな方式がある。一般的なものとしては、次のようなものが含まれる：
１）ランダム発送。要求は、負荷分散装置によってランダムに選択されたアクティブな処理ユニットに割り当てられる。平均して、負荷は処理ユニットの間で均等に分配される。この方式は、さまざまなハッシュ関数によって実装できる。
２）ラウンドロビン式発送。負荷分散装置は要求を、複数のアクティブな処理ユニットに順繰りに割り当てる。これは処理ユニットが均等に割り当てられることを維持する。
３）重み付きラウンドロビン式発送。より高い容量の処理ユニットがより多くの要求にサービスするようグループ内の各処理ユニットに重みが割り当てられる。たとえば、負荷分散装置は、より低速の処理ユニットに割り当てられる要求一つについて、より高速の処理ユニットに二つの要求を割り当ててもよい。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
エネルギー効率に関してこれらのまたは関連する方式の共通した欠点は、負荷分散装置は散らばったやり方でアクティブな処理ユニットにはいってくる要求を分配するということである。そうする際、個々の各処理ユニットは、たとえ統計的にかなりの時間にわたってアイドルであっても、負荷分散装置から頻繁に到着する要求を扱わなければならない。結果として、処理ユニットは深い低電力状態にはいる機会がめったにないことになる。頻繁な覚醒は、処理ユニットが、深いスリープ状態にはいることを妨げてしまう。
【課題を解決するための手段】
【０００７】
本願発明は、従来技術の欠点を請求項記載の手段によって軽減または解消する。
【図面の簡単な説明】
【０００８】
【図１】ある実施形態に基づく、処理ユニット・クラスターのトポロジーを示すブロック図である。
【図２】ある実施形態における処理ユニットへの要求のタイミングおよび分布を示す図である。
【図３】ある実施形態におけるバッチ処理および低電力状態のタイミングを示す図である。
【図４】ある実施形態の全体的な動作を示すフローチャートである。
【図５】ある実施形態に基づく、要求の受信およびバッチの編成を示すフローチャートである。
【図６】ある実施形態に基づく、バッチ・サイズの適応的な修正を示すフローチャートである。
【図７】ある実施形態の動作を示すフローチャートである。
【図８】ソフトウェアまたはファームウェア実施形態を示すブロック図である。
【発明を実施するための形態】
【０００９】
図面において、参照符号の左端の数字がその参照符号が最初に現れる図面を同定する。
【００１０】
本稿では、一組のサーバーのような処理ユニットの間で、処理ユニットに低電力の期間を許容するような仕方で、負荷を均衡化する方法およびシステムについて論じる。これは処理ユニットのエネルギー効率のよい動作を許容する。プロセスは、システム応答時間の変動に適応可能であってもよく、それにより、動作条件が指定するときにシステム応答時間が改善されうる。
【００１１】
図１は、サーバーのクラスターのような一組の処理ユニット１２０〜１２２の例を示している。処理ユニットははいってくる要求１０５にサービスするために協働する。要求１０５は負荷分散装置１１０において受信される。次いで負荷分散装置は要求を処理ユニットに、後述する仕方で分配する。
【００１２】
サーバーのクラスターにおいて負荷を均衡化させるシステムが図２に示されている。タイムライン２１０が示されており、この時間の間に要求２２０が負荷分散装置において受信されうる。要求２２０は、負荷分散装置に到着するにつれて処理ユニットに送られてもよい。特定の処理ユニットに送られた要求の数が所定のバッチ・サイズに達したら、その後の要求は次の処理ユニットに送られうる。この後者の処理ユニットに送られた数が前記バッチ・サイズに達するまで、この後者の処理ユニットに要求が送られうる。後続のそれぞれの処理ユニットに後続の要求のバッチが送られて、このプロセスが続いていく。バッチが最後の処理ユニットに送られてしまうと、次のバッチは第一の処理ユニットに送られる。よって、要求のバッチは、個々に、ラウンドロビン式に処理に発送される。図の例では、バッチ・サイズは３である。処理ユニットに発送された要求の数が３に達したら、次の三つの要求のバッチが次の処理ユニットに発送されうる。
【００１３】
第一のバッチ２２１は三つの要求を含んでおり、負荷分散装置に到着するにつれて第一の処理ユニット２５１に送られうる。第四の要求が受信されたら、この要求は次の処理ユニット２５２に送られうる。同様に、次の二つの要求は前記次の処理ユニット２５２に発送されうる。したがって、三つの要求からなる第二のバッチ、バッチ２２２は、このバッチ内の個々の要求が負荷分散装置に到着するにつれて、処理ユニット２５２に発送される。同様に、次のバッチ２２３は次の処理ユニット２５３に送られてもよい。この例では三つの処理ユニットがあるので、第四のバッチは第一の処理ユニット２５１に送られてもよく、その次のバッチ２２５は第二の処理ユニット２５２に送られてもよい。バッチは、ラウンドロビン式に処理ユニットに発送され続けてもよい。
【００１４】
この構成は、任意の所与の処理ユニットが要求のバッチの処理と次のバッチの処理の間でかなりの期間にわたってアイドルになり低電力状態にはいることを許容する。図示したシステムでは、所与の処理ユニットはバッチにサービスしてもよく、次いで二つの他のバッチが他の処理ユニットによって扱われうる間、アイドルであってもよい。たとえば処理ユニット２５２はバッチ２２２を扱ってもよく、次いで他のユニットによってバッチ２２３および２２４が処理されうる間アイドルであってもよい。処理ユニット２５２は、バッチ２２５が負荷分散装置によって発送されるまで、動作を再開する必要はないことがありうる。
【００１５】
一般に、m個の処理ユニットがある場合、いかなる所与の処理ユニットもm個目毎のバッチを扱う。バッチの処理後、処理ユニットは、次のm−1個のバッチが他の処理ユニットによって処理されうる間、アイドルになり低電力状態にはいってもよい。これは図３に示されている。タイムライン３５１は処理ユニット２５１における要求のバッチの受領を示し；タイムライン３５２は処理ユニット２５２における要求のバッチの受領を示し；タイムライン３５３は処理ユニット２５３における要求のバッチの受領を示す。タイムライン３５１は処理ユニット２５１について、全体における第一のバッチ２２１と全体における第四のバッチ２２４の処理の間に、アイドル区間３６１を含む。区間３６１の間、バッチは他の処理ユニットによって扱われうるので、処理ユニット２５１はこの区間の間、低電力状態にはいりうる。同様に、タイムライン３５２は、処理ユニット２５２について、システムの第二のバッチ２２２とシステムの第五のバッチ２２５の処理の間に、アイドル区間３６２を含む。
【００１６】
この図は要求三個分のサイズであるバッチを示していることに注意されたい。この数は単に例示のためであり、限定を表すものではない。代替的な実施形態では、バッチは異なるサイズであってもよい。また、図３は三つの処理ユニットを示しているが、代替的な実施形態では処理ユニットの数はより少なくてもより多くてもよい。
【００１７】
ある実施形態の処理が図４に示されている。４１０において、受信された要求が、要求が受信されるにつれて処理ユニットに発送されうる。上で論じたように、ひとたびある処理ユニットに発送された要求の数がバッチ・サイズに達したら、後続の要求のバッチは次の処理ユニットに送られうる、などとなる。４３０において、バッチ・サイズが必要に応じて調整されてもよい。バッチ・サイズを変える決定は、要求を扱うためのシステム応答時間に依存してもよい。システム応答時間は個々の要求についての応答時間の関数であってもよい。個別的な要求についての応答時間は、負荷分散装置における要求の受領から処理ユニットにおけるその要求の処理の完了までの期間を表す。バッチ・サイズは、要求にサービスするためのシステム応答時間が指定された範囲から変わる場合に変更されてもよい。たとえば、システム応答時間が過剰であれば、バッチ・サイズを縮小する決定がなされてもよい。これは、所与の処理ユニットに発送される一連の要求の数がそれほど大きくなくなることを意味する。バッチ・サイズが小さくされると、負荷分散装置において時間にわたって要求が受領されてある処理ユニットに発送されるが、より迅速にバッチ・サイズが達成される。これは、負荷分散装置におけるいかなる待ち行列遅延をも短縮しうる。したがって、要求はより早くに処理ユニットに到達する。したがって、バッチ・サイズが小さくされるとシステム応答時間は改善されうる。
【００１８】
もう一つの実施形態では、バッチ・サイズを増やしてもシステム応答時間を著しく劣化させるおそれがないときにはバッチ・サイズを大きくする決定がなされてもよい。そのような変化は処理ユニットのためのアイドル区間の長さを長くしうる。これは、処理ユニットがより長い期間にわたって低電力状態にあることを許容し、よってエネルギーを節約することになる。
【００１９】
要求の発送（図４の４１０）は、ある実施形態に基づいて図５においてより詳細に示されている。５１０では、要求が受信されたかどうかについて判定がなされてもよい。受信されていなければ、５１０は要求が受信されるまで繰り返されてもよい。要求が受信されると、プロセスは５２０において要求がサーバーのような処理ユニットに発送される段階に続きうる。５３０では、この処理ユニットに連続して発送された要求の数がバッチ・サイズに達したかどうかについての判定がなされてもよい。もしそうであれば、このバッチについての発送プロセスは５４０で終結してもよい。５３０においてこの処理ユニットに連続して発送された要求の数がまだバッチ・サイズに達していないと判定された場合には、プロセスは５１０に続きうる。
【００２０】
バッチ・サイズの適応的な調整が、ある実施形態に基づいて図６に示されている。６１０において、システム応答時間が判定されてもよい。システム応答時間は、負荷分散装置において要求が受信された時点に始まる、処理ユニットが要求にサービスするのに必要とされうる時間を記述する。したがって、システム応答時間は、個々の要求が処理されうる時間の長さの関数でありうる。システム応答時間はいくつかの方法のうちのいずれで計算されてもよい。一つの方法は、最も最近の要求を考え、その要求にサービスするのに必要とされた時間を判別することである。その後、この個別的な応答時間がシステム応答時間として扱われることになる。もう一つの可能性は、何個かの最も最近の個別的な応答を考えて、これらの個別的な応答時間の平均またはメジアンを判別することである。この実施形態において考慮されうる要求の数は、所定の値であってもよいし、あるいはたとえばバッチ・サイズであってもよい。もう一つの可能性は、たとえば最後の二分間など、ある先行する時間期間にサービスされた要求のいくつかまたは全部を考慮して、この期間にサービスされた要求についての個別的な応答時間の平均またはメジアンを判別することでありうる。あるいはまた、平均やメジアンとは異なる関数を使ってもよい。システム応答時間を決定するためのこれらのさまざまな方法は種々の実施例を表しており、本願の範囲を限定することは意図されていないことを注意しておく。
【００２１】
６２０では、６１０で計算されたシステム応答時間が上限閾値を超えるかどうかについての判定がされてもよい。上限閾値は、所望のサービス品質を維持しつつ許される最大のシステム応答時間を表すか、他の仕方でこれに関係していてもよい。この上の閾値を超えると、それに反応して、６３０でのバッチ・サイズの縮小につながりうる。上限閾値を超えない場合には、プロセスは６４０で終結してもよい。
【００２２】
バッチ・サイズの縮小幅は固定でも可変でもよい。たとえば、システム応答時間が上限閾値を超えるときは常にバッチ・サイズは６３０において固定量だけ減少させられてもよい。あるいはまた、減少は、異なる状況の下では異なっていてもよい。システム応答時間が上限閾値をより大きく超える場合には、バッチ・サイズはより大きく減少させられてもよい。これは、システム応答時間が著しく増大する場合に、バッチ・サイズのより速い調整を許容することになる。同様に、システム応答時間がより穏やかに上限閾値を超えている場合には、バッチ・サイズの減少はより穏やかであってもよい。したがって、バッチ・サイズが調整されうる程度は、システム応答時間が受け容れ可能な範囲から変動する量に相関付けられていてもよい。
【００２３】
ある実施形態の処理のより詳細な図解が図７に与えられている。７１０で、変数nが0に初期化されうる。ここで、nは要求の次のバッチが発送される処理ユニットを指示するために使われうる。７１５で、変数rが0に初期化される。ここで、rは、特定の処理ユニットに発送された連続する要求の数を指示するために使われうる。７２０において、負荷分散装置において要求が受信されたかどうかについて判定がなされてもよい。もし受信されていなければ、プロセスが要求を待つ間、７２０は繰り返される。要求が受信された場合には、７３０において、その要求が処理ユニットnに発送される。
【００２４】
７３５では、rは1だけインクリメントされうる。処理ユニットnに連続して発送された要求の数が７３０において1だけ増加したからである。７４０において、処理ユニットnに連続して発送された要求の数rがバッチ・サイズに等しいかどうかについての判定がなされてもよい。今、発送された要求rの数がバッチ・サイズに等しければ、７５０において、rは0にリセットされてもよい。これが次の処理ユニットに発送された連続する要求の数だからである。７６０では、nはmを法として1だけインクリメントされてもよい。ここで、mは利用可能な処理ユニットの数に等しい。これは、後続のバッチが次の処理ユニット（mod  m）に送られることを許容する。この構成は、任意の所与の処理ユニットが、要求のバッチの処理と処理の間に長時間にわたってアイドルになり、低電力状態にはいることを許容する。
【００２５】
７７０では、上で論じたようにシステム応答時間が決定される。７８０では、システム応答時間が上限閾値を超えるかどうかについての判定がなされてもよい。システム応答時間が上限閾値を超える場合、７９０において、バッチ・サイズが小さくされてもよい。次いでプロセスは７２０に戻って別の要求を待ってもよい。
【００２６】
いくつかの実施形態では、システム応答時間が十分速いときには、代わりに、バッチ・サイズを大きくしてもよい。この場合においてバッチを大きくすることによって、任意の所与の処理ユニットについてのバッチとバッチの間のアイドル時間を長くし、それにより電力消費を低下させることができる。このことは７８３および７８６に示されている。７８０でシステム応答時間が上限閾値を超えていないと判定される場合、７８３において、システム応答時間が下限閾値より短いかどうかについての判定がなされてもよい。もしそうでなければ、システム応答時間は上限閾値と下限閾値の範囲内にあり、プロセスは７２０に戻って別の要求を待ってもよい。システム応答時間が下限閾値を下回る場合には、７８６においてバッチ・サイズを大きくしてもよい。
【００２７】
処理ユニットおよびエネルギー消費の管理のための上記のシステムは、ハードウェア、ファームウェアもしくはソフトウェアまたはそれらの何らかの組み合わせにおいて実装されうる。さらに、本稿に記載される任意の一つまたは複数の特徴は、離散的なおよび集積された回路論理、特定用途向け集積回路（ASIC）論理およびマイクロコントローラを含むハードウェア、ファームウェアおよびそれらの組み合わせにおいて実装されてもよく、ドメイン固有の集積回路パッケージまたは集積回路パッケージの組み合わせの一部として実装されてもよい。本稿で使われるソフトウェアという用語は、コンピュータ・システムに本稿に開示された一つまたは複数の特徴および／または特徴の組み合わせを実行させるコンピュータ・プログラム論理が記憶されているコンピュータ可読媒体を含むコンピュータ・プログラム・プロダクトを指す。
【００２８】
上記の処理のソフトウェアまたはファームウェアの実施形態が図８に示されている。システム８００は、プロセッサ８４０と、コンピュータ・プログラム論理８２０を記憶する一つまたは複数のコンピュータ可読媒体を含みうるメモリ８１０のボディとを含んでいてもよい。メモリ８１０は、たとえばハードディスクおよびドライブ、コンパクト・ディスクのようなリムーバブル・メディアおよびドライブまたは読み出し専用メモリ（ROM）デバイスの一つまたは複数として実装されてもよい。プロセッサ８４０とメモリ８１０は、バスのような、当業者に既知のいくつかの技術のうちのいずれを使って通信してもよい。メモリ８１０に含まれる論理は、プロセッサ８４０によって読まれ、実行されてもよい。まとめてI/O  ８３０と示されている一つまたは複数のI/Oポートおよび／またはI/Oデバイスもプロセッサ８４０およびメモリ８１０に接続されていてもよい。ある実施形態では、システム８００は、図１に示されるような負荷分散装置に組み込まれてもよい。
【００２９】
コンピュータ・プログラム論理８２０は、発送モジュール８２２を含んでいてもよい。発送モジュール８２２は、受信された要求のバッチを一連の処理ユニットのうちの個別のものに発送する役割を担っていてもよい。コンピュータ・プログラム論理８２０はまた、システム応答時間判別モジュール８２４を含んでいてもよい。モジュール８２４は要求にサービスするためのシステム応答時間を判別する役割を担っていてもよい。上で論じたように、この判別は、入力として、最も最近の要求についての個別的な応答時間または最も最近の諸要求の組または部分集合についての個別的な応答時間を使ってもよい。コンピュータ・プログラム論理８２０はまた、判別されたシステム応答時間が閾値を超える場合にバッチ・サイズを変更する役割を担うバッチ・サイズ調整モジュール８２６を含んでいてもよい。上記したように、システム応答時間が上の閾値を超える場合にはバッチ・サイズは小さくしてもよい。代替的な実施形態では、システム応答時間が下の閾値を下回る場合にはバッチ・サイズは大きくされてもよい。調整の大きさは変動してもよく、システム応答時間が受け容れ可能な範囲から逸脱する度合いに相関していてもよい。
【００３０】
本稿では、方法およびシステムが、機能、特徴およびその関係を示す機能的な構成ブロックを援用して開示されている。これらの機能的な構成ブロックの境界の少なくともいくつかは、本稿では、記述の便宜のために任意に定義されている。指定された機能およびその関係が適切に実行される限り、代替的な境界が定義されてもよい。
【００３１】
さまざまな実施形態が本稿において開示されているが、これらは限定ではなく単に例として呈示されているのであることを理解しておくべきである。本稿に開示される方法およびシステムの精神および範囲から外れることなくそれに形および詳細においてさまざまな変更がなしうることは当業者には明白であろう。よって、特許請求の幅および範囲は、本稿に開示される例示的な実施形態のいずれによっても限定されるべきではない。
【符号の説明】
【００３２】
１０５  要求
１１０  負荷分散装置
１２０  処理ユニット
１２１  処理ユニット
１２２  処理ユニット
２１０  タイムライン
２２０  要求
２２１  バッチ
２２２  バッチ
２２３  バッチ
２２４  バッチ
２２５  バッチ
２５１  処理ユニット
２５２  処理ユニット
２５３  処理ユニット
３５１  タイムライン
３５２  タイムライン
３５３  タイムライン
３６１  アイドル期間
３６２  アイドル期間
４１０  要求を発送
４３０  必要に応じてバッチ・サイズを調整
５１０  要求を受信？
５２０  要求を発送
５３０  発送された要求数＝バッチ・サイズ？
５４０  戻る
６１０  応答時間を決定
６２０  システム応答時間＞上の閾値？
６３０  バッチ・サイズを縮小
６４０  戻る
７１０  n＝0
７１５  r＝0
７２０  要求を受信？
７３０  要求を処理ユニットnに発送
７３５  r＝r＋1
７４０  r＝ハッチ・サイズ？
７５０  r＝0
７６０  n＝n＋1  mod  m
７７０  応答時間を決定
７８０  システム応答時間＞上の閾値？
７８３  システム応答時間＜下の閾値？
７８６  バッチ・サイズを拡大
７９０  バッチ・サイズを縮小
８００  システム
８１０  メモリ
８２０  コンピュータ・プログラム論理
８２２  発送モジュール
８２４  システム応答時間決定モジュール
８２６  バッチ・サイズ調整モジュール
８３０  I/O
８４０  プロセッサ
【図１】
2011134330.tif 000003
【図２】
2011134330.tif 000004
【図３】
2011134330.tif 000005
【図４】
2011134330.tif 000006
【図５】
2011134330.tif 000007
【図６】
2011134330.tif 000008
【図７】
2011134330.tif 000009
【図８】
2011134330.tif 000010