(57)【要約】ウェブサーバ（１０４）に保存されている情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを受信することと、該情報コンポーネントに対するそれぞれが情報コンポーネントの識別子を有する１個または複数の第２のＨＴＴＰ要求メッセージを生成することと、第２のＨＴＴＰ要求メッセージを第２のウェブサーバ（１１０）に送信することを含む、方法、装置およびコンピュータ可読媒体。
2006508478.tif 000002
【特許請求の範囲】
【請求項１】
第１のウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを、クライアントから受信することと、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成することと、
第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信すること
を含む方法。
【請求項２】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を含む請求項１記載の方法であって、
ＵＲＬが所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む方法。
【請求項３】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含む請求項１記載の方法であって、
ＨＴＴＰ法が所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む方法。
【請求項４】
第２のウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析すること
をさらに含む、請求項１記載の方法。
【請求項５】
それぞれの第２のＨＴＴＰ要求メッセージに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信することと、
ＨＴＴＰ応答メッセージを解析すること
をさらに含む、請求項４記載の方法。
【請求項６】
第１のＨＴＴＰ要求メッセージが、第１のウェブサーバから供給された第１のセッションクッキーを含む、請求項１記載の方法であって、
第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信する前に、第１のセッションクッキーを、各第２のＨＴＴＰ応答メッセージの、第２のウェブサーバによって供給され第１のセッションクッキーと関連付けられている第２のセッションクッキーへと置換すること
をさらに含む方法。
【請求項７】
第１のＨＴＴＰ要求メッセージに応答して、第１のＨＴＴＰ応答メッセージを第１のウェブサーバから受信することと、
第１のウェブサーバから供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ応答メッセージを解析することと、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、第２のＨＴＴＰ応答メッセージを第２のウェブサーバから受信することと、
第２のウェブサーバから供給された第２のセッションクッキーを入手するために、第２のＨＴＴＰ応答メッセージを解析することと、
第１および第２のセッションクッキーを関連付けること
をさらに含む、請求項１記載の方法。
【請求項８】
第１のセッションクッキーおよび第１のウェブサーバに保存された同一または別の情報コンポーネントの識別子を有する第３のＨＴＴＰ要求メッセージを、クライアントから受信することと、
それぞれが別の情報コンポーネントの識別子および第２のセッションクッキーを有する、１個または複数の第４のＨＴＴＰ要求メッセージを生成すること、
第４のＨＴＴＰ要求メッセージを第２のウェブサーバに送信すること
をさらに含む、請求項７記載の方法。
【請求項９】
第１のウェブサーバによって供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ要求メッセージを解析することと、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信することと、
第２のウェブサーバによって供給された第２のセッションクッキーを入手するために、ＨＴＴＰ応答メッセージを解析することと、
第１および第２のセッションクッキーを関連付けること
をさらに含む、請求項１記載の方法。
【請求項１０】
ウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを受信することと、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成することと、
第２のＨＴＴＰ要求メッセージをウェブサーバに送信すること
を含む方法。
【請求項１１】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を含む請求項１０記載の方法であって、
ＵＲＬが所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む方法。
【請求項１２】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含む請求項１０記載の方法であって、
ＨＴＴＰ法が所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む方法。
【請求項１３】
ウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析すること
をさらに含む、請求項１０記載の方法。
【請求項１４】
それぞれの第２のＨＴＴＰ要求メッセージに応答して、ＨＴＴＰ応答メッセージをウェブサーバから受信することと、
ＨＴＴＰ応答メッセージを解析すること
をさらに含む、請求項１３記載の方法。
【請求項１５】
第１のウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを、クライアントから受信することと、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成することと、
第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信すること
を含む方法を実行するための、コンピュータによって実行可能な命令を具現化するコンピュータ可読媒体。
【請求項１６】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を含み、該方法が
ＵＲＬが所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む請求項１５記載の媒体。
【請求項１７】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含み、該方法が
ＨＴＴＰ法が所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む、請求項１５記載の媒体。
【請求項１８】
該方法が、
第２のウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析すること
をさらに含む、請求項１５記載の媒体。
【請求項１９】
該方法が、
それぞれの第２のＨＴＴＰ要求メッセージに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信することと、
ＨＴＴＰ応答メッセージを解析すること
をさらに含む、請求項１８記載の媒体。
【請求項２０】
第１のＨＴＴＰ要求メッセージが、第１のウェブサーバから供給された第１のセッションクッキーを含み、該方法が
第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信する前に、第１のセッションクッキーを第２のＨＴＴＰ応答メッセージのそれぞれの、第２のウェブサーバによって供給され第１のセッションクッキーと関連付けられた第２のセッションクッキーへと置換すること
をさらに含む、請求項１５記載の媒体。
【請求項２１】
該方法が、
第１のＨＴＴＰ要求メッセージに応答して、第１のＨＴＴＰ応答メッセージを第１のウェブサーバから受信することと、
第１のウェブサーバから供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ応答メッセージを解析することと、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、第２のＨＴＴＰ応答メッセージを第２のウェブサーバから受信することと、
第２のウェブサーバから供給された第２のセッションクッキーを入手するために、第２のＨＴＴＰ応答メッセージを解析することと、
第１および第２のセッションクッキーを関連付けること
をさらに含む、請求項１５記載の媒体。
【請求項２２】
該方法が、
第１のセッションクッキーおよび第１のウェブサーバに保存された同一または別の識別子を有する第３のＨＴＴＰ要求メッセージを、クライアントから受信することと、
それぞれが別の情報コンポーネントの識別子および第２のセッションクッキーを有する、１個または複数の第４のＨＴＴＰ要求メッセージを生成することと、
第４のＨＴＴＰ要求メッセージを第２のウェブサーバに送信すること
をさらに含む、請求項２１記載の媒体。
【請求項２３】
該方法が、
第１のウェブサーバによって供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ要求メッセージを解析することと、
第２のＨＴＴＰ要求メッセージのうち１個に応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信することと、
第２のウェブサーバによって供給された第２のセッションクッキーを入手するために、ＨＴＴＰ応答メッセージを解析することと、
第１および第２のセッションクッキーを関連付けること
をさらに含む、請求項１５記載の媒体。
【請求項２４】
ウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを受信することと、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成することと、
第２のＨＴＴＰ要求メッセージをウェブサーバに送信すること
を含む方法を実行するための、コンピュータによって実行可能な命令を具現化するコンピュータ可読媒体。
【請求項２５】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を含み、該方法が
ＵＲＬが所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む請求項２４記載の媒体。
【請求項２６】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含み、該方法が
ＨＴＴＰ法が所定の基準を満たす場合のみ、生成工程および送信工程を実行すること
をさらに含む、請求項２４記載の媒体。
【請求項２７】
該方法が、
ウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析すること
をさらに含む、請求項２４記載の媒体。
【請求項２８】
該方法が、
それぞれの第２のＨＴＴＰ要求メッセージに応答して、ＨＴＴＰ応答メッセージをウェブサーバから受信することと、
ＨＴＴＰ応答メッセージを解析すること
をさらに含む、請求項２７記載の媒体。
【請求項２９】
第１のウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを、クライアントから受信する第１のウェブサーバと、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成し、第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信するマルチプライヤ
を備える装置。
【請求項３０】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を有し、マルチプライヤが、ＵＲＬが所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項２９記載の装置。
【請求項３１】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含み、マルチプライヤが、ＨＴＴＰ法が所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項２９記載の装置。
【請求項３２】
マルチプライヤが、第２のウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析する、請求項２９記載の装置。
【請求項３３】
マルチプライヤが、
それぞれの第２のＨＴＴＰ要求メッセージに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信し、
ＨＴＴＰ応答メッセージを解析する
請求項３２記載の装置。
【請求項３４】
第１のＨＴＴＰ要求メッセージが、第１のウェブサーバから供給された第１のセッションクッキーを含み、マルチプライヤが、第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信する前に、第１のセッションクッキーを、各第２のＨＴＴＰ応答メッセージの、第２のウェブサーバによって供給され第１のセッションクッキーと関連付けられている第２のセッションクッキーへと置換する、請求項２９記載の装置。
【請求項３５】
マルチプライヤが
第１のＨＴＴＰ要求メッセージに応答して、第１のＨＴＴＰ応答メッセージを第１のウェブサーバから受信し、
第１のウェブサーバから供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ応答メッセージを解析し、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、第２のＨＴＴＰ応答メッセージを第２のウェブサーバから受信し、
第２のウェブサーバから供給された第２のセッションクッキーを入手するために、第２のＨＴＴＰ応答メッセージを解析し、
第１および第２のセッションクッキーを関連付ける
請求項２９記載の装置。
【請求項３６】
マルチプライヤが
第１のセッションクッキーおよび第１のウェブサーバに保存された同一または別の識別子を有する第３のＨＴＴＰ要求メッセージを、クライアントから受信し、
それぞれが別の情報コンポーネントの識別子および第２のセッションクッキーを有する、１個または複数の第４のＨＴＴＰ要求メッセージを生成し、
第４のＨＴＴＰ要求メッセージを第２のウェブサーバに送信する
請求項３５記載の装置。
【請求項３７】
マルチプライヤが
第１のウェブサーバによって供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ要求メッセージを解析し、
第２のＨＴＴＰ要求メッセージのうち一つに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信し、
第２のウェブサーバによって供給された第２のセッションクッキーを入手するために、ＨＴＴＰ応答メッセージを解析し、
第１および第２のセッションクッキーを関連付ける
請求項２９記載の方法。
【請求項３８】
ウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを受信するウェブサーバと、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成し、第２のＨＴＴＰ要求メッセージをウェブサーバに送信するマルチプライヤ
を備える装置。
【請求項３９】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を有し、マルチプライヤが、ＵＲＬが所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項３８記載の装置。
【請求項４０】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含み、マルチプライヤが、ＨＴＴＰ法が所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項３８記載の装置。
【請求項４１】
マルチプライヤが、ウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析する請求項３８記載の装置。
【請求項４２】
マルチプライヤが、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、ウェブサーバからＨＴＴＰ応答メッセージを受信し
ＨＴＴＰ応答メッセージを解析する
請求項４１記載の装置。
【請求項４３】
第１のウェブサーバに保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを受信する第１のウェブサーバ手段と、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成し、第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信するマルチプライヤ手段
を備える装置。
【請求項４４】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を有し、マルチプライヤ手段が、ＵＲＬが所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項４３記載の装置。
【請求項４５】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含み、マルチプライヤ手段が、ＨＴＴＰ法が所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項４３記載の装置。
【請求項４６】
マルチプライヤ手段が、第２のウェブサーバに対する第２のＨＴＴＰ要求メッセージの効果を解析する、請求項４３記載の装置。
【請求項４７】
マルチプライヤ手段が、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信し、
ＨＴＴＰ応答メッセージを解析する、
請求項４６記載の装置。
【請求項４８】
第１のＨＴＴＰ要求メッセージが、第１のウェブサーバ手段から供給される第１のセッションクッキーを含み、マルチプライヤ手段が、第２のＨＴＴＰ要求メッセージを第２のウェブサーバに送信する前に、第１のセッションクッキーを、各第２のＨＴＴＰ応答メッセージの、第２のウェブサーバによって供給され第１のセッションクッキーと関連付けられている第２のセッションクッキーへと置換する、請求項４３記載の装置。
【請求項４９】
マルチプライヤ手段が
第１のＨＴＴＰ要求メッセージに応答して、第１のＨＴＴＰ応答メッセージを第１のウェブサーバ手段から受信し、
第１のウェブサーバ手段から供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ応答メッセージを解析し、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、第２のＨＴＴＰ応答メッセージを第２のウェブサーバから受信し、
第２のウェブサーバから供給された第２のセッションクッキーを入手するために、第２のＨＴＴＰ応答メッセージを解析し、
第１および第２のセッションクッキーを関連付ける
請求項４３記載の装置。
【請求項５０】
マルチプライヤ手段が
第１のセッションクッキーおよび第１のウェブサーバ手段上に保存された同一または別の識別子を有する、第３のＨＴＴＰ要求メッセージをクライアントから受信し、
それぞれが別の情報コンポーネントの識別子および第２のセッションクッキーを有する１個または複数の第４のＨＴＴＰ要求メッセージを生成し、
第４のＨＴＴＰ要求メッセージを第２のウェブサーバに送信する
請求項４９記載の装置。
【請求項５１】
マルチプライヤ手段が
第１のウェブサーバによって供給された第１のセッションクッキーを入手するために、第１のＨＴＴＰ要求メッセージを解析し、
それぞれ第２のＨＴＴＰ要求メッセージのうち一つに応答して、ＨＴＴＰ応答メッセージを第２のウェブサーバから受信し、
第２のウェブサーバによって供給された第２のセッションクッキーを入手するために、ＨＴＴＰ要求メッセージを解析し、
第１および第２のセッションクッキーを関連付ける
請求項４３記載の方法。
【請求項５２】
ウェブサーバ手段に保存された情報コンポーネントの識別子を有する第１のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを受信するウェブサーバ手段と、
それぞれが該情報コンポーネントの識別子を有する、該情報コンポーネントのための１個または複数の第２のＨＴＴＰ要求メッセージを生成し、第２のＨＴＴＰ要求メッセージをウェブサーバ手段に送信するマルチプライヤ手段
を備える装置。
【請求項５３】
情報コンポーネントの識別子がユニバーサルリソースロケータ（ＵＲＬ）を有し、マルチプライヤ手段が、ＵＲＬが所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項５２記載の装置。
【請求項５４】
第１のＨＴＴＰ要求メッセージがＨＴＴＰ法を含み、マルチプライヤ手段が、ＨＴＴＰ法が所定の基準を満たす場合のみ、第２のＨＴＴＰ要求メッセージを生成および送信する、請求項５２記載の装置。
【請求項５５】
マルチプライヤ手段が、ウェブサーバ手段に対する第２のＨＴＴＰ要求メッセージの効果を解析する、請求項５２記載の装置。
【請求項５６】
マルチプライヤ手段が、
第２のＨＴＴＰ要求メッセージのそれぞれに応答して、ＨＴＴＰ応答メッセージをウェブサーバ手段から受信し、ＨＴＴＰ応答メッセージを解析する
請求項５５記載の装置。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本出願は、２００２年１１月２７日に出願された米国仮特許出願第６０／４２９，８２６号の利点を特許請求し、その開示全体は参照により本明細書に含まれる。
【背景】
【０００２】
本発明は一般にウェブサーバに関し、特にウェブサーバ中のリソースリークを解決することに関する。
【０００３】
近年のネットワークサービスへの需要が急速に増加したため、この需要を満たすために製造されるウェブサーバの数および複雑さも同様に増加した。このように複雑であることから、ウェブサーバは量産される前に開発段階において、徹底的にテストされ、リアルタイムで顧客に供せられる。しかし、ひとたび製造段階にはいると、ウェブサーバのテストは難しく、明らかにされた問題も難しすぎて解決できない場合がある。一般的な問題の一つがリソースリークであり、ここではメモリ等リソースの一部がウェブサーバの安定性または性能を悪化させながら徐々に消費される。メモリリークは一般的なリソースリークの一つである。
【０００４】
ウェブサーバは、ウェブページ、ワープロ文書、表計算シート、画像、動画等、情報コンポーネントを顧客に提供する。これら情報のうちいくつかは静的であるため、さらに処理をすることなく提供することができる。他の情報コンポーネントは動的であるため、顧客に送出する前に情報コンポーネント生成処理によって情報コンポーネントを生成しなければならない。リソースリークは、情報コンポーネント生成処理の動作中にリソースが「使用中」と表示されるが、該処理が該リソースを必要としない時にもリソースが解放されないことが原因となって起こる。リソースは、メモリ、同期オブジェクト、通信ポートまたはその他有限コンピュータリソースであってもよい。リソースは決して解放されないため、同一または他の処理によっては使用できない。このようなリソースリークは、経時的に処理またはオペレーションシステム全体に不具合をきたす可能性もある。
【０００５】
プロダクションウェブサーバ中のリソースリークは、一般に非常に時間がかかり、診断および修正が難しい。
【０００６】
まず第一に、多くの場合リソースリークは非常にゆっくりと発生するため、データを収集して提示された各ソルーションの効果を評価するために数日から数週間が使われる。多くのソルーションを試みる必要がある場合、この処理は数ヶ月以上かかることもありうる。
【０００７】
第二に、リソースリークはプロダクションウェブサーバに高頻度に発生する。これらウェブサーバは信頼度が高くなければならないため、リソースリークを診断する要員はシステムを大きく修正することが許可されていないこともありうる。リソースリークを診断する一般的な方法の一つは、リーキング処理の一部を無効化することである。各部は個別に無効化および有効化される。リソースリークが消失したように見える場合、通常は無効化された部分がリークの原因である。この手法は、無効化するコンポーネントに起因する機能喪失は許容できないため、プロダクションウェブサーバ上では一般に許容されない。リソースリンクを検出および診断するために、他の診断ソフトウェアコンポーネントがよく利用される。リーク検出器等のツールは小さなリークを検出する場合非常には価値が高いが、これらツールのプロダクションサーバへの使用は多くの場合禁止されている。プロダクションウェブサーバを安定させる責任を負う管理者は、追加の診断およびデバッグソフトウェアをウェブサーバ上に立ち上げることによって、安定性を危険にさらすことをしたくない。
【０００８】
第三に多くの場合、リソースリークは特殊なまたは想定外の状況に起因して起こる。プロダクションウェブサーバ上で使用されるソフトウェアシステムの大部分は、配備される前に多くのテストを受ける。したがって、ウェブサーバの一般に使用される特性に起因するリークは珍しい。これらリークは一般に、ソフトウェアを配備する前に、検出および修正される。プロダクションウェブサーバ上にリークが検出される場合、おそらくは、重要には見えなかったこと、あるいはユーザの動作の特定の手順が予測できなかったことを理由にするのか、それほどテストを行わなかった特性に起因することが多い。一般には、プロダクションウェブサーバ上でリソースリスクを特定することは、かなり簡単である。リソースが消耗していることが観察されている。リソースリークの原因を特定することは、代表的には一般的機能のいずれにも起因しないため、はるかに難しい。代表的には、ソフトウェア中に欠陥またはバグが見出される場合、欠陥を導く状況は研究室で再現される。修正方法がひとたび提示されると、この修正方法が研究室で実装およびテストされる。このモデルは、プロダクションシステムの状況の再現は難しいため、プロダクションシステム上で検出されるリークにはうまく機能しない。プロダクションシステムの使用特性は複雑であり、特徴付けが難しい。
【概要】
【０００９】
本発明はウェブヒットマルチプライヤおよびウェブヒットリダイレクタとして知られており、方法、装置およびコンピュータ可読媒体を特徴としている。本発明は、ウェブサーバ用のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を傍受し、該要求をコピーおよび処理し、その後要求を関連するウェブサーバに転送する。本発明は、テスト対象となるウェブサーバに対するプラグインとして最も簡単に実装されるものの、ウェブクライアント（ブラウザ等）とウェブサーバとの間に存在する層であるという点において、概念的にプロキシサーバと類似している。ウェブクライアントは、あたかもウェブサーバのように、ウェブヒットマルチプライヤおよびウェブヒットリダイレクタに付属している。一方ウェブサーバは、あたかもブラウザのように、ウェブヒットマルチプライヤおよびウェブヒットリダイレクタからの要求を受信する。これは２つの態様を含む。
【００１０】
ウェブヒットマルチプライヤ
第１の態様はウェブヒットマルチプライヤであり、ウェブサーバが処理するＨＴＴＰ要求の数を増加させることによって、既存のリソースリークの大きさをより大きくする。これによってリークの検出および診断がより簡単になる。要求の増加は、既存の受信要求を増幅することによって達成される。各受信要求は記録され、ウェブサーバに複数回にわたり送信される。要求の第１のコピーは一次要求と考え、追加的なコピーは二次要求と考えることができる。
【００１１】
ウェブヒットマルチプライヤの一部は、問題となっているウェブサーバに対するプラグインとして最も簡単に実装される。ウェブヒットマルチプライヤがブラウザ（または他のＨＴＴＰクライアント）からＨＴＴＰ要求を受信する場合、プラグインは該要求を記録し、修正されない状態で要求をウェブサーバへと渡す。その後、第２のコンポーネントへと該要求を転送し、ここで該要求を複数回コピーし、各要求をテスト対象となるウェブサーバに送信する。ウェブサーバがＨＴＴＰ応答を用いて一次要求に応答する場合、ＨＴＴＰ応答はブラウザに返される。ウェブヒットマルチプライヤは二次要求に対する応答をブラウザに返すべきではない。その理由は、ブラウザはこのような要求を行わないためである。（該要求はウェブヒットマルチプライヤが行う。）
【００１２】
ウェブヒットマルチプライヤは、ウェブヒットマルチプライヤ自体によって生成された要求は増幅しない。ウェブヒットマルチプライヤは、クライアントＩＰアドレス、カスタムヘッダ等、多数の方法によって、自己の要求を認識することができる。
【００１３】
ウェブヒットマルチプライヤは、診断に役立つ追加的を有する。一実施形態では、フィルターが所定の基準に基づき要求を増幅するべきリソースを選択する。
【００１４】
最初に、ウェブヒットマルチプライヤは、要求を増幅すべきリソースを特定するフィルターを備える。ウェブサーバのあるコンポーネント中にリークが疑われると、該コンポーネントに対する要求のみを増幅させ、他のコンポーネントに対する要求は増幅されない。疑わしいコンポーネントを増幅する（または増幅しない）よう選択することは、リークの原因となるコンポーネントを絞り込む役に立つ。ウェブサーバは代表的にはユニバーサルリソースロケータ（ＵＲＬ）を介してコンポーネントおよびリソースを特定するため、ウェブヒットマルチプライヤはＵＲＬからの要求をフィルタリングし、ゼロまたはより規定された正規表現に合致するＵＲＬのみを増幅する。さらに、ユーザは増幅するべきでないＵＲＬを示すゼロまたはより正規の表現を指定することができる。（すなわち、ユーザは増幅をトリガーする正の条件または増幅を抑制する負の条件を指定できる。）
【００１５】
第２に、ウェブヒットマルチプライヤは、ウェブサーバの状態を変化させるよう意図された要求を特定するフィルターを備えるが、これら要求を増幅しない。例えば、仮にあるウェブサーバが銀行システムとして作動しているとする。クライアントが銀行のウェブサイトを介してある口座から別の口座へと資金の振り替えを要求する場合、ウェブヒットマルチプライヤはこの要求を増幅しない。ユーザは、複数回振り替えが発生して欲しくないであろう。
【００１６】
状態を変化させる要求の大部分は、ＨＴＴＰ仕様に記述されているとおり、ＨＴＴＰ  ＰＯＳＴ要求を介して処理される。ウェブヒットマルチプライヤによって、ユーザは、（「ＰＯＳＴ」または「ＧＥＴ」等）どのＨＴＴＰ法を増幅するべきかおよびどれをすべきでないかを指定することができる。（上述した）ＵＲＬに基づくフィルタリングも、望まない動作を除去するために使用することができる。
【００１７】
ウェブヒットリダイレクタ
第２の態様はウェブヒットリダイレクタであり、これによって、セカンダリテストウェブサーバが、プライマリプロダクションウェブサーバと同一のＨＴＴＰ要求を受信することができる。ウェブヒットリダイレクタはウェブヒットマルチプライヤと非常によく似ているが、ただプライマリウェブサーバに要求のコピーを送信するのではなく、コピーされた要求が処理された後テストウェブサーバに送信されることが異なっている。このことによって、診断者はテストウェブサーバを修正し、「実世界」の使用パターン環境におけるこの変化の影響を解析することができる。これは受信要求をコピーすることによって達成される。各受信要求は１回または複数回コピーされる。原本はプロダクションウェブサーバへと送信され、これは一次要求として知られている。他のコピーは１台または複数台のテストウェブサーバへと送信され、これらはテスト要求または二次要求として知られている。ウェブヒットリダイレクタでは、代表的な場合、一次要求とテスト要求は同一ではない。テスト要求は、ウェブサーバに受け入れ可能となるよう「修正」されなければならない。
【００１８】
ウェブサーバがホストするクライアントを特定する方法のゆえに、要求はテストウェブサーバに転送される前に修正されなければならない。ＨＴＴＰは処理状態を把握しないプロトコルであるため、一般にウェブサーバはどのクライアントがどの要求を行ったかは知らない。例えば、ブラウザが長い文書の「次の」ページを要求した場合、ウェブサーバはどのクライアントが要求を行ったか、すなわち、２ページを閲覧しているクライアントからか（この場合、３ページに返すべきである）、あるいは２７ページを閲覧しているクライアントからか（この場合、２８ページに返すべきである）を知る必要があるであろう。ＨＴＴＰプロトコルはこの問題を解決できないが、この制約を回避するための標準的技法が存在する。
【００１９】
業界の標準的技法は、ウェブサーバ上の状態を維持するために「クッキー」を使用することである。クッキーとは、ウェブサーバによって生成される小さな識別子であり、特定のクライアントと関連付けられている。サーバは要求に応答する際に、クッキーを生成し、応答とともにクッキーを返す。ブラウザ（またはその他クライアント）はクッキーを保存し、クッキーを後続の任意の要求とともにウェブサーバに返す。ウェブサーバは、クッキーを使用して後続の要求と該要求を行っているクライアントとを照合することができる。このクッキーは、ウェブサーバ上の現ユーザの「セッション」を確立するために使用されるため、セッションクッキーと呼ばれる。例えばユーザＡが「次ページ」を要求するかもしれない。ウェブサーバはセッションクッキー「ユーザ１」とともに１ページを返すであろう。次に、ユーザＢが「次ページ」を要求すると、ウェブサーバはセッションクッキー「ユーザ２」とともに再び１ページを返すであろう。続いて、ユーザＡが「次ページ」（２ページを意味する）を要求するかもしれない。この要求とともに、ユーザＡはセッションクッキー「ユーザ１」をウェブサーバへと返すであろう。ウェブサーバは、クッキー「ユーザ１」が既に１ページを見たユーザと関連付けられていることを覚えているため、ページ２を返す。ウェブサーバはユーザについては他のことは何も知らないが、ウェブサーバはユーザＡが次に３ページを見るはずであり、ユーザＢが次に２ページを見るはずであることを知っている。クッキーは厳密に言えばＨＴＴＰ１．０仕様の一部ではないが、すべての主要なブラウザおよびウェブサーバはこのような態様でセッションクッキーをサポートしている。
【００２０】
これによって、ウェブヒットリダイレクタに問題が発生する。ウェブサーバがクッキーの形式および意味を定義するため、一般に、あるウェブサーバからのクッキーは第２のウェブサーバに首尾よく送信することができない。第２のウェブサーバはクッキーの意味を理解しない。（例えば、クッキー「ユーザ２」を他のウェブサーバに送信すると、第２のシステム上にはユーザが一人しかいない可能性もあり、エラーが起こりうる。）２名のユーザが存在する場合であっても、第２のウェブサーバの第２のユーザは第１のウェブサーバの第２のユーザとは同一ではない。このように、ウェブヒットリダイレクタが元来はプロダクションウェブサーバに対する要求をテストウェブサーバに送信すると、テストウェブサーバは要求と関連付けられたクッキーをどう解釈するかを知らない。
【００２１】
ウェブヒットリダイレクタはプロダクションウェブサーバ上のクッキーをテストウェブサーバ上のクッキーにマッピングする。ウェブヒットリダイレクタは、プロダクションウェブサーバ上のリソース向けの要求を受信すると、要求をコピーし、プロダクションウェブサーバ上の状態を特定するクッキーをすべてテストウェブサーバ向けの対応するクッキーへと置換する。これを行うために、ウェブヒットリダイレクタはテストクッキーへのプロダクションクッキーのマップを維持する。ウェブヒットリダイレクタは、テストウェブサーバに要求を転送する前に、要求を修正し、プロダクションウェブサーバ向けのセッションクッキーをすべて、テストウェブサーバ上の使用に適したマッピングされたクッキーへと置換する。ウェブヒットリダイレクタは、診断を助けるという追加的な特性を備えている。
【００２２】
ウェブヒットリダイレクタは、ウェブヒットマルチプライヤと同一のフィルタリング特性を備えている。具体的には、ウェブヒットリダイレクタはＵＲＬからの要求のフィルタリング能力を有し、指定された正規表現に合致するＵＲＬを選択的に許可／不許可する。またウェブヒットリダイレクタは、（例えば、ＨＴＴＰ  ＧＥＴ要求の出力先を変更し、一方ではＨＴＴＰ  ＰＯＳＴ要求を無視する）ＨＴＴＰ法によるフィルタリング能力も有する。
【００２３】
一つまたは複数の実装が詳細に、添付図面および以下の説明に記載されている。他の特性もまた、説明、図面および特許請求より明らかになるであろう。
【００２４】
本明細書で使用される各参照番号の最初の桁は、該参照番号が最初に登場する図面の番号を示している。
【詳細な説明】
【００２５】
本明細書に使用されている用語「クライアント」および「サーバ」は電子装置または機構を一般に意味し、用語「メッセージ」はデジタルメッセージを意味する電子信号を一般に意味する。これら用語は、以下の説明の簡略化のために使用される。本明細書中に記載されるクライアントおよびサーバは、任意の標準汎用目的コンピュータ上で実装することもできるし、あるいは専用装置として実装することもできる。
【００２６】
多くの場合、あるウェブサーバへのアクセス量は、所定時間内にウェブサーバが受信および応答する要求の数を反映する、該サーバへの「ヒット率」によって表される。上述のとおり、プロダクションウェブサーバのユーザヒット率は、遅いリソースリークの迅速な特定または診断を可能にするには不十分なことが多い。発明者らは、リークの原因である情報コンポーネントに対するヒット率が高ければ、遅いリソースリークがより早期に顕著になると認識した。言い換えると、リソースが１ヒットあたり一定の速度でリークされる場合、ヒット率を増加させることによってリークはより顕著になり、したがって修正もより簡単になる。
【００２７】
一つの考えられるアプローチは、このようなユーザ要求をシミュレートし、シミュレーションのヒット率のみを増加させることである。例えば、ツールを使用して、サーバがある要求を達成し、新しい要求が行われると直ちに、サーバ上の情報コンポーネントからリソースを繰り返し要求することも可能であろう。このアプローチの欠点の一つは、問題の情報コンポーネントに対する要求をシミュレートするためには、どの情報コンポーネントがリークの原因となっているかを知る必要があることである。これは大きな制約である。なぜならば、どの情報コンポーネントがリークしているのかを見出すことがこのテストの主要目的であるからである！言い換えれば、負荷のどの側面がシミュレーションに関連しているかを知らない限り、プロダクションウェブサーバに対する負荷を正確にシミュレートすることは困難である。
【００２８】
図１は一実施形態による通信システム１００を示す。データ通信システム１００は、ウェブブラウザ等のクライアント１０２、ウェブサーバ１０４、プラグイン１０６、オプションのユニバーサルリソースロケータ（ＵＲＬ）フィルター１０８およびマルチプライヤ１１０を備える。ウェブサーバ１０４、ＵＲＬフィルター１０８およびマルチプライヤ１１０は、好適には１個または複数のコンピュータ上で実行する別々の処理として実装されている。プラグイン１０６は、他の実装も考えられるが、好適にはインターネットサーバアプリケーションプログラムインタフェース（ＩＳＡＰＩ）フィルターとして実装される。ウェブサーバ１０４は、ウェブページ等の１個または複数の情報コンポーネントをホストし、該情報コンポーネントはＨＴＴＰ要求を送信することによってクライアント１０２からアクセス可能である。
【００２９】
図２は一実施形態による通信システム１００によって実行される処理２００を示す。クライアント１０２は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをウェブサーバ１０４に送信する（ステップ２０２）。ＨＴＴＰ要求メッセージは自動的に、またはユーザの動作に応答して生成することができる。ＨＴＴＰ要求メッセージは、ウェブサーバ１０４上に保存された情報コンポーネントの識別子を有する。ウェブサーバ１０４は、ＨＴＴＰ要求メッセージを受信する。ＨＴＴＰ要求メッセージに応答して、ウェブサーバ１０４は従来方法に従ってＨＴＴＰ応答メッセージを生成し、ＨＴＴＰ応答メッセージをクライアント１０２に送信する（ステップ２０４）。
【００３０】
オプションのＵＲＬおよびメソッドフィルター１０８を採用する実施形態では、プラグイン１０６はＨＴＴＰ要求メッセージのコピーをフィルター１０８に送信する（ステップ２０６）。他の実施形態では、プラグイン１０６はＨＴＴＰ要求メッセージのコピーをマルチプライヤ１１０に直接送信する。フィルター１０８は、ユーザ選択可能なフィルタリング基準に従ってＨＴＴＰ要求メッセージをマルチプライヤ１１０に転送するか否か決定する。一実施形態では、フィルター１０８は正規表現を各ＨＴＴＰ要求に適用し、該表現に合致するＨＴＴＰ要求のみを転送する。別の実施形態では、フィルター１０８は該表現に合致しないＨＴＴＰ要求のみを転送することができる。第３の実施形態では、フィルター１０８は指定されたＨＴＴＰ法に合致するＨＴＴＰ要求のみを転送することができる。他の実施形態は、これら基準およびその他基準の種々の組み合わせを含んでいる。
【００３１】
この特性によって、ウェブサイトの特定部分を増幅することができるが、他の部分は増幅されない。この特性は特にリソースリークを分離するために有用である。例えばリソースリークがみとめられ、ウェブサイトの特定部分と関連していると疑われる場合、ＵＲＬフィルター１０８はウェブサイトの当該部分のみを増幅することができる。リソースリークが加速されれば、リークはウェブサイトの当該部分と関連している可能性が高い。そこで、リバーステストを実施してウェブサイトの当該部分以外のすべてを増幅させることができる。リークが増幅されなければ、リークがウェブサイトの当該部分と関連していることはきわめて確実である。
【００３２】
マルチプライヤ１１０は、転送されたＨＴＴＰ要求メッセージを受信し（ステップ２０８）、ＨＴＴＰ要求メッセージのｎ≧１である所定数ｎ個のコピーを生成する。マルチプライヤ１１０は、ＨＴＴＰ要求メッセージのコピーをウェブサーバ１１０に転送する（ステップ２１０）。このようにして、処理２００は特定の情報コンポーネントに対する全ユーザの要求を「増幅」することによって、該情報コンポーネントと関連するすべてのリソースリークの速度を増加させ、リークの特定および診断をより早期かつ高速で行う。いくつかの実施形態では、マルチプライヤ１１０は、マルチプライヤによって生成された増幅された要求に応答して、ウェブサーバ１０４から返された応答を解析する（ステップ２１２）応答解析ツールを備えることによって、追加のテストデータを提供する。
【００３３】
本発明の実施形態は、手動クリックテスト中でも、ウェブサーバをテストするために使用することができる。これら実施形態は、プロダクション環境において消費者からの要求を増幅するのではなく、開発環境において試験者からの要求を増幅する。試験者の各クリックは、ある大きな数によって乗算され、同時にクリックしている多くのユーザをシミュレートする。
【００３４】
図３は、一実施形態によるデータ通信システム３００を示す。データ通信システム３００は、ウェブブラウザ等のクライアント３０２、プロダクションウェブサーバ３０４、テストウェブサーバ３１２、プラグイン３０６、オプションのＵＲＬフィルター３０８およびマルチプライヤ３１０を備える。ウェブサーバ３０４および３１２、ＵＲＬフィルター３０８およびマルチプライヤ３１０は、好適には１個または複数のコンピュータ上で実行する別々の処理として実装されている。プラグイン３０６は、好適にはＩＳＡＰＩフィルターとして実装されている。ウェブサーバ３０４は、ウェブページ等の１個または複数の情報コンポーネントをホストし、該情報コンポーネントはクライアント３０２からアクセス可能である。ウェブサーバ３１２は、プロダクションウェブサーバ３０４によってホストされている１個または複数の情報コンポーネントをホストする。
【００３５】
図４は、一実施形態による通信システム３００によって実行される処理４００を示す。クライアント３０２は、ＨＴＴＰ要求メッセージをプロダクションウェブサーバ３０４に送信する（ステップ４０２）。ＨＴＴＰ要求メッセージは、自動的に、またはユーザの動作に応答して生成することができる。ＨＴＴＰ要求メッセージは、プロダクションウェブサーバ３０４に保存された情報コンポーネントの識別子を有する。プロダクションウェブサーバ３０４はＨＴＴＰ要求メッセージを受信する。ＨＴＴＰ要求メッセージに応答して、プロダクションウェブサーバ３０４は、従来方法に従ってＨＴＴＰ応答メッセージを生成し、ＨＴＴＰ応答メッセージをクライアント３０２に送信する（ステップ４０４）。
【００３６】
オプションのＵＲＬフィルター３０８を採用する実施形態では、プラグイン３０６はＨＴＴＰ要求メッセージのコピーをＵＲＬフィルター３０８に送信する（ステップ４０６）。他の実施形態では、プラグイン３０６はＨＴＴＰ要求メッセージのコピーをマルチプライヤ３１０に送信する。ＵＲＬフィルター３０８は、ユーザ選択可能なフィルタリング基準に従ってＨＴＴＰ要求メッセージをマルチプライヤ３１０に転送するか否か決定する（ステップ４１２）。一実施形態では、ＵＲＬフィルター３０８は正規表現を各ＨＴＴＰ要求へと適用し、該表現に合致するＨＴＴＰ要求のみを転送する。別の実施形態では、ＵＲＬフィルター３０８は該表現に合致しないＨＴＴＰ要求のみを転送することができる。他の実施形態は、これら基準およびその他基準の種々の組み合わせを含んでいる。
【００３７】
マルチプライヤ３１０は、転送されたＨＴＴＰ要求メッセージを受信し（ステップ４０８）、ＨＴＴＰ要求メッセージのｎ≧１である所定数ｎ個のコピーを生成する。マルチプライヤ３１０はＨＴＴＰ要求メッセージのコピーをテストウェブサーバ３１２に転送する（ステップ４１０）。いくつかの実施形態では、マルチプライヤ３１０は、マルチプライヤによって生成された増幅された要求に応答して、テストウェブサーバ３０２から返された応答を解析する（ステップ４１２）応答解析ツールを備えることによって、追加的なテストデータを提供する。
【００３８】
このようにして、処理４００はテストウェブサーバに対する特定のプロダクションウェブサーバ情報コンポーネントに対する全ユーザの要求を「増幅」することによって、該情報コンポーネントと関連するすべてのリソースリークの速度を増加させ、プロダクション環境を妨害することなくリークの特定および診断をより早期かつ高速で行う。さらに、カスタム化された、または既成のデバッグツールを、プロダクション環境を妨害することなく、テストウェブサーバ上で使用することもできる。
【００３９】
いくつかの実施形態はウェブセッションマッピング特性を有している。クライアントがウェブサーバに接続すると、当該クライアントのセッションの状態を、セッションクッキーを使用して追跡することが一般的である。セッションクッキーのコンテンツはウェブサーバによって決定され、クライアントへと送信され、クライアントはセッションクッキーをウェブサーバに対する後続の要求に含める。しかし、要求がプロダクションウェブサーバからテストウェブサーバへと転送されるとき、テストウェブサーバはセッションクッキーを理解しないため、セッションクッキーは転送されない。その代わりに、マルチプライヤは開発ウェブサーバおよびプロダクションウェブサーバによって生成された対応するセッションクッキー間のマッピングを維持し、適切なセッションクッキーの置換を実行する。セッションが最初に確立されるとき、セッションクッキーは存在しない。この場合マルチプライヤは、当該セッションに対してセッションクッキーマッピングが確立されていないことを認識し、プロダクションウェブサーバによってセッションクッキーが設定されることを待つ。ひとたびセッションクッキーが確立されると、マルチプライヤが要求をテストウェブサーバに転送し、開発サーバによって供給されるセッションクッキーをプロダクションウェブサーバによって供給されるセッションクッキーへとマッピングする。マルチプライヤが当該セッション中に後続の要求を受信すると、マッピングに従ってセッションクッキーを置換した後、要求をテストウェブサーバに転送する。
【００４０】
図５は、一実施形態によるマルチプライヤ３１０によって実行される処理５００を示す。マルチプライヤ３１０はプロダクションウェブサーバ（ＰＷＳ）に対する要求を受信し（ステップ５２０）、該要求がセッションクッキーを含んでいるか否かを判断する（ステップ５０４）。
【００４１】
要求がセッションクッキーを含んでいない場合、マルチプライヤ３１０は要求の１個または複数のコピーを生成し（ステップ５０６）、単数または複数のコピーをテストウェブサーバ（ＴＷＳ）に送信する（ステップ５２０）。マルチプライヤ３１０が要求に対する単数または複数の応答をテストウェブサーバから受信すると（ステップ５２２）、マルチプライヤは応答を解析して、テストウェブサーバから供給されたセッションクッキーを入手する（ステップ５２４）。またマルチプライヤ３１０は、要求の原本をプロダクションウェブサーバへと通過させる（ステップ５０８）。マルチプライヤ３１０は、要求の原本に対する応答をプロダクションウェブサーバから受信すると（ステップ５１０）、応答を解析して、プロダクションウェブサーバから供給されたセッションクッキーを入手する（ステップ５１２）。その後マルチプライヤ３１０は、ステップ５１２でプロダクションウェブサーバから入手したセッションクッキーと、ステップ５２４でテストウェブサーバから入手したセッションクッキー（複数）との間のクッキーマッピングを記録する。
【００４２】
しかし、仮にステップ５０４でセッションクッキーが要求に含まれていれば、マルチプライヤ３１０はセッションクッキーがマッピングされたか否か判断する（ステップ５２６）。
【００４３】
要求がセッションクッキーを含み、クッキーがすでにマッピングされている場合、マルチプライヤ３１０は要求の単数または複数のコピーを生成し（ステップ５４４）、コピー中にあるプロダクションウェブサーバ用セッションクッキーを、マップに基づき対応するテストウェブサーバクッキーに置換し（５４６）、修正した単数または複数のコピーをテストウェブサーバ（ステップ５４８）に送信する。そこで処理５００は終了する（ステップ５５０）。
【００４４】
しかしステップ５２６において、セッションクッキーが要求中に存在するがまだマッピングされていないとすると、マルチプライヤ３１０はプロダクションウェブサーバ（ステップ５２８）からの要求の１個または複数のコピーを生成し、コピーをテストウェブサーバに送信する（ステップ５３８）。マルチプライヤ３１０が、要求への応答をテストウェブサーバから受信すると（ステップ５４０）、応答を解析して、テストウェブサーバから供給されたセッションクッキーを入手する（ステップ５４２）。またマルチプライヤ３１０は、要求の原本を解析して要求中に存在するセッションクッキーを入手し（ステップ５３０）、要求の原本をプロダクションウェブサーバへと渡す（ステップ５３２）。次にマルチプライヤ３１０は、ステッ５３２でプロダクションウェブサーバから入手したセッションクッキーと、ステップ５４２でテストウェブサーバから入手したセッションクッキーとの間のクッキーマッピングを記録する（ステップ５３４）。次に処理５００は終了する（ステップ５３６）。一実施形態において、マルチプライヤ３１０は、ある単一の要求のすべてのコピー中において、単一のテストウェブサーバ用セッションクッキーを使用する。別の実施形態では、マルチプライヤ３１０は、単一の要求のそれぞれのコピーにおいて、異なるテストウェブサーバ用セッションクッキーを使用する。
【００４５】
本発明は、デジタル電子回路中に、またはコンピュータハードウェア、ファームウェア、ソフトウェア中にあるいはそれらの組み合わせの中で実装することができる。本発明の装置は、プログラム可能処理装置による実行のために機械によって読み取り可能な記憶装置中で目に見える形で具現化されたコンピュータプログラム成果物中で実装することができる。また、本発明の方法工程は、入力データに基づいて作動し出力を生成することによって本発明の機能を実行するための命令プログラムを実行するプログラム可能処理装置によって実行することができる。本発明は、プログラム可能なシステム上で実行可能な１個または複数のコンピュータプログラム中で、有利に実装することができる。該プログラム可能なシステムは、データおよび命令を受信し、データおよび命令を送信するために接続された少なくとも一つのプログラム可能な処理装置と、データ記憶システムと、少なくとも一つの入力装置と少なくとも一つの出力装置とを備える。各コンピュータプログラムは、高レベルの手続型プログラム言語ないしオブジェクト指向プログラム言語中で、または所望に応じてアセンブリ言語または機械語で実装することができる。いずれの場合においても、言語はコンパイラ型言語でもまたはインタープリタ型言語でもよい。適切な処理装置は、一例として、汎用マイクロプロセッサおよび特殊目的のマイクロプロセッサの両方を備えている。一般に、処理装置は命令およびデータをリードオンリーメモリおよび／またはランダムアクセスメモリから受信する。一般に、コンピュータはデータファイルを記憶するための、１個または複数の大容量記憶装置を備える。その一例は、内部ハードディスクならびにリムーバブルディスク等磁気ディスク、光磁気ディスク、および光ディスク等である。コンピュータプログラム命令およびデータを目に見える形で具現化することに適した記憶装置は、すべての形態の不揮発性メモリを含む。その一例は、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリデバイス等の半導体メモリデバイス、内部ハードディスクならびにリムーバブルディスク等磁気ディスク、光磁気ディスク、およびＣＤ−ＲＯＭディスク等である。上記のいずれも、ＡＳＩＣ（特定用途向け集積回路）によって補強され、またはＡＳＩＣに内蔵可能である。
【００４６】
ここまで本発明の多数の実装を記載されてきた。それにもかかわらず、本発明の精神および範囲から逸脱することなしに種々の修正を行うことができることが理解されるであろう。したがって、他の実装も特許請求の範囲内にある。
【図面の簡単な説明】
【００４７】
【図１】一実施形態によるデータ通信システムを示す。
【図２】一実施形態による図１の通信システムによって実行される処理を示す。
【図３】一実施形態によるデータ通信システムを示す。
【図４】一実施形態による図３の通信システムによって実行される処理を示す。
【図５】一実施形態による図１のマルチプライヤによって実行される処理を示す。
【図１】
2006508478.tif 000003
【図２】
2006508478.tif 000004
【図３】
2006508478.tif 000005
【図４】
2006508478.tif 000006
【図５】
2006508478.tif 000007
【国際調査報告】
2006508478.tif 000008
2006508478.tif 000009