(57)【要約】  本発明は、トラフィック制御方法およびトラフィック制御装置を開示する。トラフィック制御方法は、システムの主要性能指数を収集するステップと、収集されたシステムの主要性能指数に基づいて、システムに入来する要求を制限するかどうかを決定するステップであって、ある期間の間、特定の収集されたシステムの主要性能指数が第１の閾値より低いときは、システムに入来する要求が制限されるように決定される、決定するステップとを含む。本発明によれば、システムに対してトラフィック制御を効果的に、実用的に、かつ柔軟にもたらすことができる。
2014520316.tif 000002
【特許請求の範囲】
【請求項１】
トラフィック制御方法であって、
システムの主要性能指数を収集するステップと、
収集されたシステムの主要性能指数に基づいて、システムに入来する要求を制限するかどうかを決定するステップであって、ある期間の間、特定の収集されたシステムの主要性能指数が第１の閾値より低いときは、システムに入来する要求が制限されるように決定される、決定するステップと
を含む、方法。
【請求項２】
異なるインターフェースからシステムに入来する要求に対しては、それぞれのインターフェースからシステムに入来する要求を制限するかどうかは、異なる収集されたシステムの主要性能指数を用いて決定される、請求項１に記載の方法。
【請求項３】
異なるインターフェースからシステムに入来する要求に対しては、それぞれのインターフェースからシステムに入来する要求を制限するかどうかは、同じ収集されたシステムの主要性能指数を用いるが、異なる閾値を用いて決定される、請求項１に記載の方法。
【請求項４】
異なるシステムに対しては、システムに入来する要求を制限するかどうかは、異なる収集されたシステムの主要性能指数を用いて決定される、請求項１に記載の方法。
【請求項５】
システムに入来する要求が制限された後に、特定の収集されたシステムの主要性能指数がある期間の間、第２の閾値より高い場合は、システムに入来する要求の制限を終了するように決定され、第２の閾値によって表されるシステム負荷は、第１の閾値と比べて軽い、請求項１に記載の方法。
【請求項６】
システムに入来する要求が制限された後に、特定の収集されたシステムの主要性能指数がある期間の間、第３の閾値より低い場合は、システムに入来する要求をさらに制限するように決定され、第３の閾値によって表されるシステム負荷は、第１の閾値と比べて重い、請求項１に記載の方法。
【請求項７】
要求を制限することが、一定の割合の要求をランダムに拒絶することを含む、請求項１に記載の方法。
【請求項８】
トラフィック制御装置であって、
システムの主要性能指数を収集する収集部と、
収集されたシステムの主要性能指数に基づいて、システムに入来する要求を制限するかどうかを決定するための決定モジュールであって、ある期間の間、特定の収集されたシステムの主要性能指数が第１の閾値より低いときは、システムに入来する要求が制限されるように決定する、モジュールと、
を備える、装置。
【請求項９】
異なるインターフェースからシステムに入来する要求に対しては、決定モジュールは、それぞれのインターフェースからシステムに入来する要求を制限するかどうかを、異なる収集されたシステムの主要性能指数を用いて決定する、請求項８に記載の装置。
【請求項１０】
異なるインターフェースからシステムに入来する要求に対しては、決定モジュールは、それぞれのインターフェースからシステムに入来する要求を制限するかどうかを、同じ収集されたシステムの主要性能指数を用いるが、異なる閾値を用いて決定する、請求項８に記載の装置。
【請求項１１】
異なるシステムに対しては決定モジュールは、システムに入来する要求を制限するかどうかを、異なる収集されたシステムの主要性能指数を用いて決定する、請求項８に記載の装置。
【請求項１２】
システムに入来する要求が制限された後に、決定モジュールは、特定の収集されたシステムの主要性能指数がある期間の間、第２の閾値より高い場合は、システムに入来する要求の制限を終了するように決定し、第２の閾値によって表されるシステム負荷は、第１の閾値と比べて軽い、請求項８に記載の装置。
【請求項１３】
システムに入来する要求が制限された後に、決定モジュールは、特定の収集されたシステムの主要性能指数がある期間の間、第３の閾値より低い場合は、システムに入来する要求をさらに制限するように決定し、第３の閾値によって表されるシステム負荷は、第１の閾値と比べて重い、請求項８に記載の装置。
【請求項１４】
要求を制限することが、一定の割合の要求をランダムに拒絶することを含む、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理の分野に関し、より詳細には、トラフィック制御方法およびトラフィック制御装置に関する。
【背景技術】
【０００２】
通信システムなどの様々なシステムは、異なるタイプの要求によってもたらされる莫大なトラフィックをサポートしながら、安定で健全な状態に保たれるべきである。
【０００３】
特定の期間、例えばクリスマスまたは元日の間は、ユーザトラフィックは急激に増大し、システムの安定性に影響を及ぼし、さらにはシステムダウンをもたらし、正常にサービスを提供できなくなることが起こり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、システムを安定に保つようにトラフィック制御が必要となる。
【０００５】
しかし、トラフィック制御が不適切に行われた場合、システムのリソースは十分に活用されず、したがって、無駄を生じることになる。
【０００６】
そのため、必要なことは、効果的で、実用的で、かつ柔軟なトラフィック制御ソリューションであり、「効果的」とはシステムができるだけ安定に保たれることを意味し、「実用的」とはシステムリソースができるだけ十分に活用されることを意味し、「柔軟」とはトラフィック制御のカスタマイズが、できるだけ個別の条件に従って行われることを意味する。
【課題を解決するための手段】
【０００７】
本発明の第１の態様によれば、トラフィック制御方法が提供され、方法は、システムの主要性能指数を収集するステップと、収集されたシステムの主要性能指数に基づいて、システムに入来する要求を制限するかどうかを決定するステップであって、ある期間の間、特定の収集されたシステムの主要性能指数が第１の閾値より低い（ｉｎｆｅｒｉｏｒ）ときは、システムに入来する要求が制限されるように決定される、決定するステップとを含む。
【０００８】
本発明の第２の態様によれば、トラフィック制御装置が提供され、装置は、システムの主要性能指数を収集する収集部と、収集されたシステムの主要性能指数に基づいて、システムに入来する要求を制限するかどうかを決定するための決定モジュールであって、ある期間の間、特定の収集されたシステムの主要性能指数が第１の閾値より低いときは、システムに入来する要求が制限されるように決定する、モジュールとを備える。
【０００９】
本発明によれば、通信システムに対してトラフィック制御を効果的に、実用的に、かつ柔軟にもたらすことができる。
【００１０】
本発明の他の目的および効果については、図面と併せて以下の説明から、本発明の十分な理解と共に、より明らかにかつ幅広いものとなるであろう。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態によるトラフィック制御方法の例示的なフローチャートである。
【図２】本発明の一実施形態によるトラフィック制御装置の例示的なブロック図である。
【図３】本発明を実施することができる通信システムの例示的な図である。
【発明を実施するための形態】
【００１２】
上記の図面を通して同じ参照番号は、同じ、同様な、または対応する特徴または機能を表す。
【００１３】
本発明の基本的な概念は、システムの主要性能指数（Ｋｅｙ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｉｎｄｅｘ：ＫＰＩ）に基づいて、システムに入来する要求を制限するかどうかを決定することである。
【００１４】
ＫＰＩはシステムの健全性状態を反映する最も直感的な指数であり、ＣＰＵ使用率、メモリ使用率、ハードディスク読取り／書込み使用率などのシステムハードウェアリソースについての指数、ならびにキューの長さ、利用可能なプールのサイズなどのソフトウェア論理概念によって規定される指数を含む。システムに入来する要求が制限されるかどうかは、システムのＫＰＩを絶えず収集することによって合理的に決定され、すなわちシステムを安定に保ちながら、システムのリソースはできるだけ十分に活用されるようになる。
【００１５】
図１は、本発明の一実施形態によるトラフィック制御方法のフローチャートを示す。
【００１６】
図１に示されるように方法１００は、システムのＫＰＩを収集するステップＳ１１０と、収集されたシステムのＫＰＩに基づいてシステムに入来する要求を制限するかどうかを決定するステップＳ１２０とを含み、特定の収集されたシステムのＫＰＩがある期間の間、第１の閾値より低いときは、システムに入来する要求は制限されるように決定される。
【００１７】
それに従って図２は、本発明の一実施形態によるトラフィック制御装置のブロック図を示す。
【００１８】
図２に示されるようにトラフィック制御装置２００は、システムのＫＰＩを収集するための収集部２１０と、収集されたシステムのＫＰＩに基づいてシステムに入来する要求を制限するかどうかを決定する決定モジュール２２０とを備え、特定の収集されたシステムのＫＰＩがある期間の間、第１の閾値より低いときは、システムに入来する要求が制限されるように決定する。
【００１９】
例えば特定の収集されたシステムのＫＰＩは平均ＣＰＵ使用率とすることができ、第１の閾値は８０％とすることができ、平均ＣＰＵ使用率が第１の閾値より高い（ｓｕｐｅｒｉｏｒ）場合、すなわち平均ＣＰＵ使用率が８０％未満の場合は、システムは依然として安定に動作することができ、システムに入来する要求を制限する必要はない。
【００２０】
平均ＣＰＵ使用率が第１の閾値より低い場合、すなわち平均ＣＰＵ使用率が８０％を超えた場合は、システムの負荷が重すぎ、システムが不安定になり得ることを意味し、したがって決定するステップＳ１２０および決定モジュール２２０においては、平均ＣＰＵ使用率が５分の間、８０％を超えたときは、システムに入来する要求は制限されるように決定される。
【００２１】
ここで、要求を制限することは、要求がシステムに入来するエントリーポイントにおいて、一定の割合の要求をランダムに拒絶することを含み、すなわちいくつかの要求に対しは、これらの要求を処理のためにシステムの内部に届けるのではなく、失敗応答が返されることになる。例えば拒絶率は２０％とすることができ、すなわち平均で、システムに入来する１０個の要求のうち２個の要求は拒絶されることになる。
【００２２】
このようなポリシーは、ほとんどのユーザ要求は対応され、少数のユーザ要求のみが拒絶されることになるので、ユーザ体験を比較的良くすることができる。
【００２３】
ここで、決定するステップＳ１２０および決定モジュール２２０において、異なるインターフェースからシステムに入来する要求に対しては、それぞれのインターフェースからシステムに入来する要求を制限するかどうかは、異なる収集されたシステムのＫＰＩを用いて決定することができる。
【００２４】
例えばオープンＩＶＲ（対話型音声応答（Ｉｎｔｅｒａｃｔｉｖｅ  Ｖｏｉｃｅ  Ｒｅｓｐｏｎｓｅ））インターフェースを通じてシステムに入来する要求に対しては、ＣＰＵ使用率などのシステムＫＰＩを使用することができ、平均ＣＰＵ使用率が５分の間、８０％を超えた場合は、オープンＩＶＲインターフェースを通じてシステムに入来する要求を制限するように決定することができ、例えばオープンＩＶＲインターフェースを通じてシステムに入来する要求は、２０％の拒絶率で拒絶することができる。
【００２５】
ＳＭＳ（ショートメッセージサービス（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ））インターフェースを通じてシステムに入来する要求に対しては、キューの長さなどのシステムＫＰＩを使用することができ、キューの平均長さが５分の間、２０を超えた場合は、ＳＭＳインターフェースを通じてシステムに入来する要求を制限するように決定することができ、例えばＳＭＳインターフェースを通じてシステムに入来する要求は、５０％の拒絶率で拒絶することができる。
【００２６】
このようなポリシーは、異なるインターフェースからシステムに入来する要求は、システムの異なるＫＰＩに影響を及ぼし得るという事実を考慮に入れる。例えばオープンＩＶＲインターフェースを通じてシステムに入来する要求は主にシステムのＣＰＵリソースを消費し、したがって主にシステムの平均ＣＰＵ使用率などのＫＰＩに影響を及ぼし、一方、ＳＭＳインターフェースを通じてシステムに入来する要求は主にシステムのキューリソースを消費し、したがって主にキューの平均長さなどのシステムのＫＰＩに影響を及ぼす。
【００２７】
ここで、決定するステップＳ１２０および決定モジュール２２０においては、異なるインターフェースからシステムに入来する要求に対しては、それぞれのインターフェースからシステムに入来する要求を制限するかどうかは、同じ収集されたシステムのＫＰＩを用いるが、異なる閾値を用いて決定することができる。
【００２８】
例えばオープンＩＶＲ（対話型音声応答）インターフェースを通じてシステムに入来する要求に対しては、平均ＣＰＵ使用率などのＫＰＩ、および８０％などの閾値を使用して、オープンＩＶＲインターフェースを通じてシステムに入来する要求を制限するかどうかを決定することができる。平均ＣＰＵ使用率が５分の間、８０％を超えた場合は、オープンＩＶＲインターフェースを通じてシステムに入来する要求を制限するように決定することができ、例えばオープンＩＶＲインターフェースを通じてシステムに入来する要求は、１０％の拒絶率で拒絶することができる。
【００２９】
ＳＭＳ（ショートメッセージサービス）インターフェースを通じてシステムに入来する要求に対しては、平均ＣＰＵ使用率などのＫＰＩ、および７０％などの閾値を使用して、ＳＭＳインターフェースを通じてシステムに入来する要求を制限するかどうかを決定することができる。平均ＣＰＵ使用率が５分の間、７０％を超えた場合は、ＳＭＳインターフェースを通じてシステムに入来する要求を制限するように決定することができ、例えばＳＭＳインターフェースを通じてシステムに入来する要求は、５０％の拒絶率で拒絶することができる。
【００３０】
このようなポリシーは、異なるインターフェースからシステムに入来する要求に対して差別化された処理を行うことができ、それにより低い優先度を有する要求を最初に制限することができ、制限された利用可能なシステムリソースはより多くの高い優先度を有する要求に対応するために用いることができる。高い優先度を有する要求は、低い優先度を有する要求を制限するだけでは依然としてシステム負荷を低くできないときにのみ制限することができる。すなわち低い優先度を有する、ＳＭＳインターフェースを通じてシステムに入来する要求は、平均ＣＰＵ使用率が５分の間、７０％を超えるとすぐに制限されるようになり、一方、高い優先度を有する、オープンＩＶＲインターフェースを通じてシステムに入来する要求は、平均ＣＰＵ使用率が５分の間、８０％を超えない限りは制限されないことになる。
【００３１】
ここで、決定するステップＳ１２０および決定モジュール２２０において、異なるシステムに対しては、システムに入来する要求を制限するかどうかは、異なる収集されたシステムのＫＰＩを用いて決定することができる。
【００３２】
システムが集中的な浮動小数点計算を行う必要がある（例えばシステムがプリペイド課金システムである）場合、浮動小数点計算はＣＰＵリソース消費型であるので、システムに入来する要求を制限するかどうかは、システムの平均ＣＰＵ使用率などのシステムＫＰＩを用いて決定することができる。
【００３３】
例えば第１の閾値は８０％に設定することができ、すなわち平均ＣＰＵ使用率が５分の間、８０％を超えた場合は、システムに入来する要求を制限するように決定することができる。
【００３４】
一部のシステムの場合、ＣＰＵ／メモリ／ハードディスク読取りおよび書込み使用率の点からなど、ハードウェアの点からはシステムは、その負荷が非常に重くてさらに多くの到来する要求に対応できないということは示さないが、ソフトウェア論理の点からはシステムは、その負荷が非常に重くてさらに多くの到来する要求に対応できないことを示しており、例えば実行キューにおいて多数の待機要求が存在し、または多数の要求がＪＤＢＣ接続を求めて待機している。したがってシステムに入来する要求を制限するかどうかは、システムの実行キューの平均長さ、またはＪＤＢＣ接続を求めて待機している要求の平均数などのシステムＫＰＩを用いて決定することができる。
【００３５】
例えば第１の閾値は２０に設定することができ、すなわち実行キューの平均長さが５分の間、２０を超えた場合は、システムに入来する要求を制限するように決定することができる。
【００３６】
あるいは第１の閾値は３０に設定することができ、すなわちＪＤＢＣ接続を求めて待機している要求の平均数が５分の間、３０を超えた場合は、システムに入来する要求を制限するように決定することができる。
【００３７】
このようなポリシーはシステムにおける差異を考慮し、異なるシステムに対しては、システムに入来する要求を制限するかどうかは、異なる収集されたシステムのＫＰＩを用いて決定することができる。
【００３８】
ここで、決定するステップＳ１２０および決定モジュール２２０において、システムに入来する要求が制限された後に、特定の収集されたシステムのＫＰＩがある期間の間、第２の閾値より高い場合は、システムに入来する要求の制限を終了するように決定され、第２の閾値によって表されるシステム負荷は、第１の閾値と比べて軽い。
【００３９】
例えばシステムに入来する要求が制限された後に、平均ＣＰＵ使用率などのＫＰＩはシステム負荷が軽くなったことを示す場合があり、これはシステムに入来する要求に対する前の制限が効力を生じたことを意味し、システムの安定性は維持され、したがってシステムリソースができるだけ十分に活用されるようにするために、システムに入来する要求に対する制限は終了されるべきである。
【００４０】
しかし、システムに入来する要求の制限と、システムに入来する要求の制限の終了との間での頻繁な切り換えを避けるために、システムに入来する要求の制限を終了するように決定するための第２の閾値によって表されるシステム負荷は、システムに入来する要求を制限するように決定するための第１の閾値によって表されるものより軽くするべきである。
【００４１】
例えば第１の閾値が８０％である場合は、第２の閾値は６０％とすることができ、すなわち平均ＣＰＵ使用率が５分の間、６０％未満であったときは、システムに入来する要求の制限を終了するように決定される。
【００４２】
ここで、決定するステップＳ１２０および決定モジュール２２０においては、システムに入来する要求が制限された後に、収集されたシステムのＫＰＩがある期間の間、第３の閾値より低い場合は、システムに入来する要求をさらに制限するように決定することができ、第３の閾値によって表されるシステム負荷は、第１の閾値と比べて重い。
【００４３】
例えばシステムに入来する要求が制限された後に、平均ＣＰＵ使用率などのＫＰＩが、システム負荷が軽くならずさらに重くなったことを示す場合があり、これはシステムに入来する要求に対する前の制限が十分でなかったことを意味し、システム負荷をより低くさせ、それによってシステムの安定性を維持するように、システムに入来する要求をさらに制限する必要がある。
【００４４】
例えば第１の閾値が８０％である場合は、第３の閾値は９０％とすることができ、すなわち平均ＣＰＵ使用率が５分の間、９０％を超えた場合は、システムに入来する要求をさらに制限するように決定することができ、それによりシステムに入来する要求の拒絶率は５０％に達する。
【００４５】
もちろん当業者には、システムに入来する要求がさらに制限された後に、平均ＣＰＵ使用率などのＫＰＩが、システム負荷が軽くならずさらに重くなったことを示し、これはシステムに入来する要求に対する前のさらなる制限が十分でなかったことを意味し、システムに入来する要求を再びさらに制限してシステム負荷をより低くさせることができ、それによってシステムの安定性を維持することが理解されるであろう。
【００４６】
例えば平均ＣＰＵ使用率が５分の間、９５％を超えた場合は、システムに入来する要求を再びさらに制限するように決定することができ、それによりシステムに入来する要求の拒絶率は１００％に達し、システムを安定に保つためにシステムに到来する要求の受付けを一時的に中断させる。
【００４７】
図３は、本発明を実施することができるシステムを例示的に示す。
【００４８】
図３に示されるシステム３００は、個人用リングバックトーン（Ｐｅｒｓｏｎａｌｉｚｅｄ  Ｒｉｎｇ  Ｂａｃｋ  Ｔｏｎｅ：ＰＲＢＴ）システムのコンテンツ管理システム（Ｃｏｎｔｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ：ＣＭＳ）である。
【００４９】
ここでＰＲＢＴシステムは、ＰＲＢＴサービスのユーザが、ユーザ自身の必要性に基づいて異なる呼び出し番号に対して異なる期間において異なるリングバックトーンを設定することを可能にする。
【００５０】
ＰＲＢＴシステムは２つの部分、すなわちＰＲＢＴ−ＣＤＳ（トーン再生システム）および、ＰＲＢＴ−ＣＭＳを含むことができる。ＰＲＢＴ−ＣＤＳは、呼を受け取り、発呼者に対して個人用リングバックトーンを再生することを受け持ち、ＰＲＢＴ−ＣＭＳは、ＰＲＢＴユーザのためのユーザデータおよびトーンファイルの管理を受け持つ。
【００５１】
図３に示されるようなＰＲＢＴ−ＣＭＳ３００は、ユーザがそれらと対話するために以下の４つのタイプのインターフェースを提供する：
Ｗｅｂインターフェース３２２、
オープンＡＰＩインターフェース３２４、
オープンＩＶＲインターフェース３２６、
ＳＭＳインターフェース３２８。
【００５２】
これらのインターフェースからの要求は、まずＰＲＢＴ−ＣＭＳ３００のＷｅｂサーバ３３０に到着し、次いでＷｅｂサーバ３３０によってＷｅｂｌｏｇｉｃサーバインスタンス３３２−１、３３２−２、・・・、３３２−Ｎのうちの１つに送出される。ここでそれぞれのＷｅｂｌｏｇｉｃサーバインスタンスは、データベース（ＤＢ）サーバ３３４に接続される。
【００５３】
ＰＲＢＴ−ＣＭＳ３００に入来するすべての要求は、Ｗｅｂサーバ３３０を通じてＷｅｂｌｏｇｉｃサーバインスタンス３３２−１、３３２−２、・・・、３３２−Ｎのうちの１つに送出されることを考慮すると、したがってＷｅｂサーバ３３０はＰＲＢＴ−ＣＭＳ３００に入来するすべての要求に対するエントリーポイントであるので、ＰＲＢＴ−ＣＭＳ３００に入来する要求を制限するかどうかはＷｅｂサーバ３３０において決定されるべきである。言い換えれば、上記の決定モジュール２２０は、Ｗｅｂサーバ３３０において実装されるべきである。
【００５４】
さらにＷｅｂサーバ３３０、Ｗｅｂｌｏｇｉｃサーバインスタンス３３２−１、３３２−２、・・・、３３２−Ｎ、およびＤＢサーバ３３４は、すべてのインターフェースによって共有されるリソースであり、したがってそれらのＫＰＩが収集されるべきである。
【００５５】
図３に示されるような例ではＷｅｂｌｏｇｉｃサーバインスタンス３３２−１、３３２−２、・・・、３３２−ＮはＰＲＢＴ−ＣＭＳ３００の主要処理デバイスであると仮定すると、ＰＲＢＴ−ＣＭＳ３００のＫＰＩはＷｅｂｌｏｇｉｃサーバインスタンスのみに関係する。さらに図３に示されるような例では、Ｗｅｂｌｏｇｉｃサーバインスタンス３３２−Ｎは、他のＷｅｂｌｏｇｉｃサーバインスタンス３３２−１、３３２−２、・・・を管理するための管理インスタンスである。したがって上記の収集部２１０は、Ｗｅｂｌｏｇｉｃサーバインスタンス３３２−Ｎにおいて実装される。
【００５６】
収集部２１０は、ＰＲＢＴ−ＣＭＳ３００についてのＫＰＩを絶えず収集する。例えば収集部２１０は、ＷｅｂｌｏｇｉｃサーバのＪＭＸ（Ｊａｖａ（登録商標）管理エクステンション（Ｊａｖａ  Ｍａｎａｇｅｍｅｎｔ  Ｅｘｔｅｎｓｉｏｎ））インターフェースにおいて提供されるＭｂｅａｎ（管理ビーン（Ｍａｎａｇｅｍｅｎｔ  Ｂｅａｎ））クラスおよびメソッドを通じて、ＷｅｂｌｏｇｉｃサーバインスタンスについてのＫＰＩを絶えず収集する。決定モジュール２２０はまた、収集部２１０によって収集されたＫＰＩを絶えず問い合わせ、ＫＰＩがシステムに入来する要求を制限するための閾値に一致することを見出したときは、一定の割合の要求を拒絶し始める。
【００５７】
収集部２１０によって収集されるＫＰＩは、非限定的に以下の項目を含む：
（１）Ｗｅｂｌｏｇｉｃサーバの健全性状態：すなわちＷｅｂｌｏｇｉｃサーバインスタンスの現在のライフサイクル状態
【００５８】
（２）Ｎ個のＷｅｂｌｏｇｉｃサーバインスタンスにおけるアクティブなサーバインスタンスの数：各Ｗｅｂｌｏｇｉｃサーバインスタンスがアクティブであるかどうかは、それぞれのＷｅｂｌｏｇｉｃサーバインスタンスにＣＭＳオープンＡＰＩ問い合わせ要求を送ることによって識別することができ、Ｗｅｂｌｏｇｉｃサーバインスタンスが成功の結果を返した場合は、Ｗｅｂｌｏｇｉｃサーバインスタンスはアクティブであると見なされる。
【００５９】
（３）各Ｗｅｂｌｏｇｉｃサーバインスタンスに対して構成された実行キューにおける待機要求の数：これは優先キューにおける待機状態のユーザ要求の数を規定する。優先キューは通常は内部サブシステムおよび外部ユーザからの要求を含んでおり、ＰｅｎｄｉｎｇＵｓｅｒＲｅｑｕｅｓｔＣｏｕｎｔの値がすべての外部ユーザ要求の数である。
【００６０】
（４）各Ｗｅｂｌｏｇｉｃサーバインスタンスの各リスニングポート上に確立されたソケットの数：Ｗｅｂｌｏｇｉｃサーバインスタンスによって現在開かれているソケットの数は、ＯｐｅｎＳｏｃｋｅｔｓＣｕｒｒｅｎｔＣｏｕｎｔを用いて取得することができる。
【００６１】
（５）すべてのプロセッサの平均負荷：各ＷｅｂｌｏｇｉｃサーバインスタンスにおけるＣＰＵ使用率
【００６２】
概して、操作者の観点からは、Ｗｅｂインターフェース３２２、オープンＩＶＲインターフェース３２６、およびＳＭＳインターフェース３２８からの要求はエンドユーザからの要求で、オープンＡＰＩインターフェース３２４からの要求はサードパーティシステムからの要求であり、ＰＲＢＴサービスでのエンドユーザ体験を良好に保つためには、Ｗｅｂインターフェース３２２、オープンＩＶＲインターフェース３２６、およびＳＭＳインターフェース３２８からの要求の優先度は、オープンＡＰＩインターフェース３２４からの要求の優先度よりも高くすべきである。したがって操作者は、Ｗｅｂインターフェース３２２、オープンＩＶＲインターフェース３２６、およびＳＭＳインターフェース３２８からの要求は制限せず、オープンＡＰＩインターフェース３２４からの要求のみを制限するように構成することができる。
【００６３】
さらにこの例では、システムに入来する要求を制限するかどうかは、各Ｗｅｂｌｏｇｉｃサーバインスタンスの各リスニングポート上に確立されたソケットの数のＫＰＩに基づいて決定され、第１の閾値は１００であり、第２の閾値は４０である。
【００６４】
すなわちリスニングポート上に確立されたソケットの数の最大値が４０秒の間、１００を超えた場合は、オープンＡＰＩインターフェース３２４からの要求は制限されるようになり、要求の５０％は拒絶されるようになり、すなわち拒絶率は５０％となる。
【００６５】
オープンＡＰＩインターフェース３２４からの要求が制限された後に、リスニングポート上に確立されたソケットの数の最大値が４０秒の間、４０未満であった場合は、オープンＡＰＩインターフェース３２４からの要求に対する制限は終了されることになる。
【００６６】
本発明の理解を容易にするために、上記の説明は、当業者には知られているが本発明を実施するために必要となり得る、一部のより具体的な技術的詳細が省かれていることに留意されるべきである。
【００６７】
当業者にはまた、本発明は上述のステップに限定されず、本発明は上述のステップに対して行われる組み合わせ、順序の変更なども包含することが理解されるべきである。本発明の最終的な範囲は添付の特許請求の範囲によって規定される。
【００６８】
したがって実施形態は、本発明の本質から逸脱しないことを前提として、本発明の原理および実用的な適用例を最も良く説明し、当業者が、すべてのそのような変更および変形が、特許請求の範囲によって規定される本発明の範囲に含まれることを理解できるように、選ばれ説明されている。
【００６９】
さらに当業者には上述の様々な方法のステップは、プログラムされたコンピュータによって実施できることが理解されるであろう。ここで一部の実施形態は、機械またはコンピュータ可読であり、機械実行可能またはコンピュータ実行可能な命令プログラムによってコード化され、命令は上記の方法のステップの一部またはすべてを行う、プログラム記憶装置を包含することを意図することが理解されるであろう。プログラム記憶装置は、磁気ディスク、または磁気テープ、ハードディスク駆動装置などの磁気記憶媒体、または光学的読取り可能デジタルデータ記憶媒体とすることができる。実施形態はまた、上記の方法のステップを行うようにプログラムされたコンピュータを包含することが意図される。
【図１】
2014520316.tif 000003
【図２】
2014520316.tif 000004
【図３】
2014520316.tif 000005
【国際調査報告】
2014520316.tif 000006
2014520316.tif 000007