JP6343625B2

JP6343625B2 - 推定装置及び推定方法

Info

Publication number: JP6343625B2
Application number: JP2016033515A
Authority: JP
Inventors: 川口　銀河; 銀河川口
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-02-24
Filing date: 2016-02-24
Publication date: 2018-06-13
Anticipated expiration: 2036-02-24
Also published as: JP2017151722A

Description

本発明は、推定装置及び推定方法に関する。

インターネットの利用が普及している中で、ウェブブラウザを快適に利用できるかどうかは、ユーザが「インターネットを快適に利用できるか」に大きく影響する。

そのため、ユーザがウェブページを閲覧する際にブラウザを操作し、ブラウザがデータを読み込み・表示をするまでにかかる時間（以下、「ウェブページ表示時間」という。）を把握し、管理することが品質管理上重要である。

ウェブページ表示時間を把握するため、ブラウザにはNavigationTiming等の仕組みが供えられ、直接表示時間を知る手法なども普及してきている（非特許文献１、非特許文献２）。

本多他、「Navigation Timing APIを用いたWeb品質劣化切り分け」、コミュニケーションクオリティ研究会2014. 「Navigation Timing」、［online］、［平成２７年１０月２６日検索］、インターネット（URL：http://www.w3.org/TR/navigation-timing/） H. Drucker, et al.,``Support Vector Regression Machines'',Advances in Neural Information Processing Systems 9, NIPS 1996,

しかしながら、NavigationTiming技術については、コンテンツ事業者（ウェブサーバ）やユーザ（クライアント端末）において利用されることが想定されており、データ転送を担当するキャリアが管理するネットワーク上において観測されるデータに対して適用することは困難である。

本発明は、上記の点に鑑みてなされたものであって、ネットワーク上の観測データからウェブブラウザの快適性を推定可能とすることを目的とする。

そこで上記課題を解決するため、推定装置は、ウェブブラウザでのウェブページの表示に関する複数回の試行のそれぞれにおいて観測された所定数のＧＥＴリクエストのＵＲＬのうち、各試行に含まれる割合が第１の閾値以上であるＵＲＬのリストを生成するリスト生成部と、前記試行ごとに、前記所定数のＧＥＴリクエストのうち、前記リストに含まれるＵＲＬに係るＧＥＴリクエストの比率を算出する算出部と、前記試行ごとに、前記所定数のＧＥＴリクエストの試行内での相対的な発生時期、前記比率、及び前記リストに含まれる各ＵＲＬに係るＧＥＴリクエストの前記相対的な発生時期を含む情報と、前記試行ごとに計測された、前記ウェブページの表示が指示されてから、少なくとも前記ウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間との関係を、第１の推定モデルに学習させる第１のモデル生成部と、ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第１の推定モデルを適用して、前記所要時間を推定する第１の推定部と、
を有する。

ネットワーク上の観測データからウェブブラウザの快適性を推定可能とすることができる。

第１の実施の形態における推定装置のハードウェア構成例を示す図である。第１の実施の形態における推定装置の機能構成例を示す図である。第１の実施の形態において推定装置が実行する処理手順の一例を説明するためのフローチャートである。学習データを構成するＨＴＴＰ−ＧＥＴの発生履歴を示す図である。学習データを構成する転送完了時間及び表示完了時間の履歴の例を示す図である。第１の実施の形態における各試行についての学習閾値分のレコードの抽出結果の一例を示す図である。各ＨＴＴＰ−ＧＥＴの発生時刻の相対時刻への変換結果の一例を示す図である。試行ごとの転送完了時間又は表示完了時間のベクトルの一例を示す図である。第２の実施の形態における推定装置の機能構成例を示す図である。第２の実施の形態において推定装置が実行する処理手順の一例を説明するためのフローチャートである。第２の実施の形態における各試行についての学習閾値分のレコードの抽出結果の一例を示す図である。ＵＲＬごとの観測比率の算出結果の一例を示す図である。共通ＵＲＬリストの一例を示す図である。共通ＵＲＬ比率の算出結果及び各共通ＵＲＬの相対時刻の算出結果の一例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。まず、ウェブページの閲覧・表示におけるプロセスについて説明する。当該プロセスを極めて単純化すると、以下の通りである。
（１）ユーザによるクリック等を起点としたページ取得要求が発生する。
（２）ブラウザが対象ＵＲＬの指すページのｈｔｍｌデータについてＨＴＴＰ（HyperText Transfer Protocol）のＧＥＴリクエストで転送を要求すると、ｈｔｍｌデータがブラウザに転送される。
（３）ｈｔｍｌデータ内にサブコンテンツ（画像データ、必要ｓｃｒｉｐｔ等）が示されており、ブラウザは、それらを順次解読処理し、ＨＴＴＰのＧＥＴリクエストで取得する（ＨＴＴＰでＧＥＴ）。
（４）ブラウザは順次取得したサブコンテンツを処理して表示する。

一般のウェブページの閲覧では、ｈｔｔｐｓで暗号化されていない場合は、ネットワーク上でのパケットのやり取りを読み取る（パケットキャプチャする）ことで、個別のＨＴＴＰのＧＥＴリクエスト（以下、「ＨＴＴＰ−ＧＥＴ」と表記する。）の送出状況及び送出時刻を把握することが出来る。そこで、（４）の表示処理の分を省略して、少なくとも（１）から（３）までの所要時間（≒ウェブページの表示が指示されてから表示に必要なデータのブラウザへの転送が完了するまでの所要時間）を知ることが出来れば、簡易的に表示完了時間を推定することができる。以下、この「ウェブページの表示が指示されてから表示に必要なデータのブラウザへの転送が完了するまでの所要時間」を、単に、「転送完了時間」という。また、（１）〜（４）までの所要時間を、「表示完了時間」という。

しかし、ＨＴＴＰ−ＧＥＴを観測することで、「転送完了時間」を特定するには以下の２点の問題がある。
（ａ）ウェブページの作りによっては、自動更新等により、ウェブページの表示完了後もＨＴＴＰ−ＧＥＴが継続して発生する。
（ｂ）同じウェブページを同じ端末で繰り返し表示した場合、表示完了までに生じるＨＴＴＰ−ＧＥＴの数が必ずしも一定ではない。

まず、（ａ）により、一つのウェブページに関して「ＨＴＴＰ−ＧＥＴの発生が終了するタイミング」はネットワーク上でＧＥＴリクエストの発生状況を観測する範囲では判断できないため、そもそも表示用データの転送の完了は、ＨＴＴＰ−ＧＥＴの転送の完了と対応しない。

また、（ｂ）により、ウェブページ毎にＨＴＴＰ−ＧＥＴの数に関して一定の閾値を事前に決定し、ＨＴＴＰ−ＧＥＴのシーケンスを観測して当該閾値にＧＥＴ回数が到達した時点をもってＨＴＴＰ−ＧＥＴの転送の完了と判断することも困難である。

そこで、本実施の形態では、転送完了（上記の（３）の完了）よりも手前の段階（上記の（３）の途中までの段階）でのＨＴＴＰ−ＧＥＴの発生履歴から、転送完了時間又は表示完了時間を推定する。

図１は、第１の実施の形態における推定装置のハードウェア構成例を示す図である。図１の推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、推定装置１０は、それぞれが図１に示される構成を有する複数のコンピュータによって構成されてもよい。

図２は、第１の実施の形態における推定装置の機能構成例を示す図である。図２において、推定装置１０は、学習データ取得部１１、閾値決定部１２、推定モデル生成部１３、及び推定部１４等を有する。これら各部は、推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。推定装置１０は、また、学習データ記憶部１５を利用する。学習データ記憶部１５は、例えば、補助記憶装置１０２、又は推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

学習データ取得部１１は、予め設定されたＵＲＬに係る、評価対象のウェブページ（以下「評価対象ページ」という。）について、転送完了時間又は表示完了時間の推定のための学習データを取得する。推定の対象が転送完了時間であれば、転送完了時間に関する学習データが取得され、推定の対象が表示完了時間であれば、表示完了時間に関する学習データが取得される。推定の対象が、転送完了時間及び表示完了時間のいずれであるかは、予め設定される。学習データは、ネットワークキャプチャデータの取得や、ウェブブラウザにおけるウェブページに関するデータ転送の完了又はウェブページの表示の完了等のタイミングの検知等を並行して実行することで取得される。学習データ取得部１１は、同一の評価対象ページに関して複数回にわたって繰り返し行われるウェブページの表示指示及び表示ついて、ページ転送完了の時刻若しくはページ表示完了の時刻、及び転送されたＨＴＴＰ−ＧＥＴ（ＨＴＴＰのＧＥＴリクエスト）の発生履歴を示す学習データを取得する。取得された学習データは、学習データ記憶部１５に記憶される。

閾値決定部１２は、学習データに基づいて、転送完了時間又は表示完了時間の推定に用いるＨＴＴＰ−ＧＥＴの数（閾値）を決定する。

推定モデル生成部１３は、閾値決定部１２によって決定された閾値の範囲内の学習データを、統計的な推定モデルに学習させる。

推定部１４は、学習データを学習した推定モデルを、ネットワーク上において観測された観測データ（ＧＥＴリクエストの発生履歴）に対して適用して、転送完了時間及び表示完了時間のうち、推定対象として設定された方を推定する。

以下、推定装置１０が実行する処理手順について説明する。図３は、第１の実施の形態において推定装置が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１１０において、学習データ取得部１１は、予めそのＵＲＬが設定されている評価対象ページを、推定装置１０内のブラウザに表示させ、その際のＨＴＴＰ−ＧＥＴの発生履歴と、ブラウザによる評価対象ページの転送完了時間又は表示完了時間との実績値を取得する。学習データ取得部１１は、取得されたデータ（学習データ）を、学習データ記憶部１５に記憶する。なお、ＨＴＴＰ−ＧＥＴの発生履歴については、転送の開始から転送完了時間までのものが取得される。すなわち、転送完了時間より後のＨＴＴＰ−ＧＥＴについては、当該発生履歴に含まれない。

ＨＴＴＰ−ＧＥＴの発生履歴については、例えば、推定装置１０内のｔｃｐｄｕｍｐ等のパケットキャプチャツールでパケットデータを取得した後、ｔｓｈａｒｋ等のキャプチャ解析ツールで、当該パケットデータをＨＴＴＰ−ＧＥＴの発生数及び時刻に変換することで取得されてもよい。例えば、キャプチャデータファイル名がｄｕｍｐ．ｐｃａｐであるとすると、以下のコマンドを実行することで、ＨＴＴＰ−ＧＥＴの発生数、時刻、及びＵＲＬを得ることができる。
%tshark -r dump.pcap -Y http.request.uri -T fields -e frame.time_epoch-e http.request.full_uri ......
又は、推定装置１０内にプロキシを設定し、ブラウザによるウェブページの表示時のプロキシログからＨＴＴＰ−ＧＥＴの時刻情報のログが取得されてもよい。

一方、ブラウザでの評価対象ページの転送完了時間及び表示完了時間については、例えば、NavigationTimingのＡＰＩ（Application Program Interface）により計測して数値化が可能である。

なお、ステップＳ１１０の１回の実行を、「試行」という。ステップＳ１１０は、事前に設定された試行回数（例えば、１０１回等）分だけ繰り返される。その結果、図４及び図５に示される情報によって構成される学習データが、取得される。

図４は、学習データを構成するＨＴＴＰ−ＧＥＴの発生履歴を示す図である。図４において、ＨＴＴＰ−ＧＥＴの発生履歴は、各試行において検出されたＨＴＴＰ−ＧＥＴごとに、試行番号、ＵＲＬ、及び時刻等を含む。

試行番号は、何番目の試行において検出されたＧＥＴリクエストであるのかを示す値である。ＵＲＬは、ＧＥＴリクエストの宛先のＵＲＬである。時刻は、ＧＥＴリクエストが発生した（検出された）時刻である。なお、試行ごとに、ＧＥＴリクエストの数は異なりうるため、図４において、試行ごとの行数は異なりうる。

図５は、学習データを構成する転送完了時間及び表示完了時間の履歴の例を示す図である。図５には、各試行における、評価対象ページの転送完了時間及び表示完了時間が示されている。なお、推定の対象が転送完了時間である場合、転送完了時間のみが取得されてもよく、表示完了時間である場合、転送完了時間及び表示完了時間が取得されてもよい。

なお、図４と図５とにおいて、試行番号が共通するレコードは、同じ試行番号に関する学習データである。例えば、図５において、試行２（試行番号が２である試行）に関するＨＴＴＰ−ＧＥＴの発生履歴は、図４において試行番号が２であるレコードを参照することで特定できる。

なお、評価対象ページの表示に関する試行は、推定装置１０とは異なる端末において実行されてもよい。この場合、ステップＳ１１０では、学習データが入力されるだけでよい。

続いて、閾値決定部１２は、予め設定されている閾値決定法及びパラメータを、学習データに適用することで、閾値を決定する（ステップＳ１２０）。

まず、閾値決定部１２は、ＨＴＴＰ−ＧＥＴ発生履歴（図４）について、試行ごとのレコード数を集計し、集計結果を昇順にソートする。図４の例では、試行１の集計結果は４であり、試行２の集計結果は５である。

続いて、閾値決定部１２は、予め設定されている閾値決定法及びパラメータに基づいて、閾値を決定する。本実施の形態では、「分布の下位パーセンタイル指定」で、ソートした数字の小さい側から、事前に決められた分位点が閾値として決定される。

例えば、閾値決定法が、「分布の下位５パーセンタイル」であれば、ソート結果の最小値から５％の位置（すなわち、１０１回試行の場合、最小値から６個目の値）が閾値として決定される。

この理由は、最小値を用いると、異常終了してしまったサンプル等が含まれる場合、最小値が極めて小さくなり、推定に必要な適正なデータ数が得られない可能性があるためである。そこで、一定の分位点抽出で対応する。

以上により決定された閾値を、「学習閾値Ｎ」という。

続いて、推定モデル生成部１３は、ＨＴＴＰ−ＧＥＴ発生履歴（図４）について、試行ごとに、時刻の値が小さい方から学習閾値Ｎ個分のレコード（すなわち、発生時期の早い順にＮ個のＧＥＴリクエストに関するレコード）を抽出する（ステップＳ１３０）。なお、レコードの数が学習閾値Ｎ未満である試行については、レコードの抽出は行われない。

図６は、第１の実施の形態における各試行について学習閾値分のレコードの抽出結果の一例を示す図である。図６では、レコードの抽出が行われた試行ごとに、試行番号、Ｎ個分のＨＴＴＰ−ＧＥＴの発生時刻が示されている。なお、図６では、Ｍ個の試行が、学習閾値Ｎ個以上のレコードを含んでいた例に対応する。

続いて、推定モデル生成部１３は、レコードが抽出された試行ごとに、各ＨＴＴＰ−ＧＥＴの発生時刻を、当該試行の最初のＨＴＴＰ−ＧＥＴの発生時刻からの相対値（相対時刻）に変換する（ステップＳ１４０）。すなわち、図６に示される各試行のＧＥＴ−Ｘ（Ｘ＝１〜Ｎ）時刻について、ＧＥＴ−１時刻からの差分（試行内の相対的な発生時期）が算出される。

図７は、各ＨＴＴＰ−ＧＥＴの発生時刻の相対時刻への変換結果の一例を示す図である。図７には、図６に示した各試行の各ＨＴＴＰ−ＧＥＴの発生時刻について、相対時刻への変換結果が示されている。なお、ＧＥＴ−１時刻については、各試行について、相対時刻は常に０となり情報量が無いので破棄する。その結果、各試行の列数はＮ−１となる。

続いて、推定モデル生成部１３は、（ＧＥＴ数がＮ以上であった）試行ごとに、転送完了時間又は表示完了時間のベクトルを生成する（ステップＳ１５０）。

図８は、試行ごとの転送完了時間又は表示完了時間のベクトルの一例を示す図である。図８において、（１）は、図５に示した学習データに基づいて生成された、転送完了時間のベクトルである。（２）は、図５に示した学習データに基づいて生成された、表示完了時間のベクトルである。なお、推定対象が転送完了時間であれば、転送完了時間のベクトルのみが生成されてもよく、推定対象が表示完了時間であれば、表示完了時間のベクトルのみが生成されてもよい。

続いて、推定モデル生成部１３は、予め設定された推定方法に基づいて、推定モデルを生成する（ステップＳ１６０）。本実施の形態では、推定方法として、サポートベクター回帰（ＳＶＲ：SupportVectorRegression）が設定された例について説明する。但し、本実施の形態に適用可能な推定方法は、ＳＶＲに限定されず、他の方法が用いられてもよい。例えば、重回帰等が用いられてもよい。なお、ＳＶＲ自体は、単なる機械学習の既知の手法であり、本実施の形態では、入力データの使い方及び出力とのマッピングがポイントである。

ここでは、学習データ（Ｘ）を以下のように構成する。
Ｘ＝（Ｘ＿１，Ｘ＿２，...，Ｘ＿（Ｎ−１））
但し、
Ｘ＿１＝［各試行のＧＥＴ−２の相対時刻の長さＭのベクトル］
＝［０．０３２，０．２００，...，０．２２２］（図７の例）
Ｘ＿（Ｎ−１）＝［０．２３３，０．６６８，...，１．２２３］
また、学習データ（Ｙ）を以下のように構成する。
転送完了時間が推定対象である場合、
Ｙ＝［転送完了時間の長さＭのベクトル］＝［２．５，２．９，...，４．１］
表示完了時間が推定対象である場合、
Ｙ＝［表示完了時間の長さＭのベクトル］＝［３．１，３．６，...，４．７］
推定モデル生成部１３は、ＳＶＲのモデルＥを生成し、上記のように構成した学習データ（Ｘ）及び学習データ（Ｙ）で学習させる。すなわち、ＸとＹとの関係を、モデルＥに学習させる。

例えば、ＳＶＲの機能を持っているscikit-learnのライブラリにおける、ＳＶＲの使い方（http://scikit-learn.org）に準じれば、以下の記述によって、モデルＥの生成と、学習とを行うことができる。
E=SVR() #モデル生成
E.fit(X、Y) #学習データで学習
続いて、推定部１４は、モデルＥを、ネットワーク上の観測データに対して適用し、当該観測データに関して、転送完了時間又は表示完了時間を推定する（ステップＳ１７０）。

具体的には、推定部１４は、ネットワーク上において時系列に観測された評価対象ページに関する各ＨＴＴＰ−ＧＥＴの発生時刻の履歴を取得する。推定部１４は、当該各ＨＴＴＰ−ＧＥＴの発生時刻について、最初のＨＴＴＰ−ＧＥＴの発生時刻からの相対的な発生時期（相対時刻）を算出する。その結果、相対時刻のベクトルＸ＿ｎｅｗが得られる。

例えば、観測された各ＨＴＴＰ−ＧＥＴの発生時刻の履歴が、以下の通りであったとする。
ＧＥＴ発生時刻の履歴：（２３４５．３３３，２３４５．９９９，２３４６．５００，２３４７．０００）
この場合、Ｘ＿ｎｅｗの値は、以下の通りとなる。
Ｘ＿ｎｅｗ＝［０．６６６，１．１６７，...，１．６６７］
推定部１４は、Ｘ＿ｎｅｗを推定モデルＥに適用し、推定値Ｔ＿ｅを得る。
Ｔ＿ｅ＝Ｅ．ｐｒｅｄｉｃｔ（Ｘ＿ｎｅｗ）
このように推定されたＴ＿ｅの値（例えば、３．８）が、観測データに関する「転送完了時間」又は「表示完了時間」の推定値である。すなわち、学習データ（Ｙ）が転送完了時間のベクトルであれば、転送完了時間の推定値が得られる。学習データ（Ｙ）が表示完了時間のベクトルであれば、表示完了時間の推定値が得られる。

なお、転送完了時間及び表示完了時間の双方の推定値が得られてもよい。

また、複数のＵＲＬのそれぞれごとに推定モデルを生成しておき、ネットワークにおいて観測されたＧＥＴリクエストに係るＵＲＬに対応する推定モデルを利用して、転送完了時間又は表示完了時間の推定が行われてもよい。

上述したように、本実施の形態によれば、ネットワーク上の観測データからウェブブラウザの快適性を推定可能とすることができる。

次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。

第１の実施の形態による（ＧＥＴ時系列のみによる推定）では、転送完了時間及び表示完了時間等の待ち時間が大きくなる領域では、推定精度が落ちる可能性が有る。これは学習データの分布の裾（異常値）領域の問題であり、もともと推定がしにくい領域であるためである。

そこで、第２の実施の形態では、以下の２つのいずれか、又は双方を行うことで、精度低下問題を改善する。
（ａ）毎回の表示（試行）において共通的に観測される割合の高い「共通ＵＲＬ」のＨＴＴＰ−ＧＥＴにおける挙動を学習データに加味する。
（ｂ）推定結果として「待ち時間が大きい」と判断された場合に、待ち時間が大きい範囲に特化した推定器で再推定を実施する。

以下の説明において、（ａ）のみが実施されるケースを「ケースＡ」という。また、（ｂ）のみが実施されるケースを「ケースＢ」という。更に、（ａ）及び（ｂ）の双方が実施されるケースを「ケースＣ」という。

図９は、第２の実施の形態における推定装置の機能構成例を示す図である。図９中、図２と同一部分には同一符号を付し、その説明は適宜省略する。

図９において、推定装置１０は、更に、共通ＵＲＬリスト生成部２１、共通ＵＲＬ比率算出部２２、異常閾値決定部２３、再推定モデル生成部２４、及び再推定部２５を有する。これら各部は、推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。推定装置１０は、また、共通ＵＲＬリスト記憶部２６を利用する。共通ＵＲＬリスト記憶部２６は、例えば、補助記憶装置１０２、又は推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

共通ＵＲＬリスト生成部２１は、ＨＴＴＰ−ＧＥＴの発生履歴（図４）において、各試行に含まれる割合（試行あたりの出現頻度）が一定の閾値以上のＵＲＬ（以下、「共通ＵＲＬ」という。）の集合（以下、「共通ＵＲＬリスト」という。）を生成する。

共通ＵＲＬ比率算出部２２は、試行ごとに、当該試行において観測されたＨＴＴＰ−ＧＥＴ群に対する共通ＵＲＬに係るＨＴＴＰ−ＧＥＴ群の比率（以下、「共通ＵＲＬ比率」という。）を算出する。共通ＵＲＬ比率は、ＵＲＬごとの観測時刻と共に学習データに加えられる。

異常閾値決定部２３は、待ち時間が大きい範囲を識別するための閾値（以下、「異常閾値」という。）を決定する。

再推定モデル生成部２４は、転送完了時間又は表示完了時間が異常閾値以上のデータに基づいて、待ち時間が大きい範囲に対応する推定モデル（以下、「再推定モデル」という。）を生成する。

再推定部２５は、推定部１４による推定結果が異常閾値より大きかった場合に、再推定モデルに基づいて転送完了時間又は表示完了時間を推定し、その推定結果によって、推定部１４による推定結果を置き換える。

図１０は、第２の実施の形態において推定装置が実行する処理手順の一例を説明するためのフローチャートである。図１０中、図３と同一ステップには同一ステップ番号を付し、その説明は省略する。

図１０では、ステップＳ１３０がステップＳ１３０ａに置換されている。ステップＳ１３０ａにおいて、推定モデル生成部１３は、ＨＴＴＰ−ＧＥＴ発生履歴（図４）について、試行ごとに、学習閾値Ｎ個分のレコードを抽出する際に、時刻だけでなくＵＲＬも抽出する。

図１１は、第２の実施の形態における各試行についての学習閾値分のレコードの抽出結果の一例を示す図である。図１１では、ＨＴＴＰ−ＧＥＴ発生履歴の各レコードから、時刻及びＵＲＬが抽出されている。

続くステップＳ１５１〜Ｓ１５４は、ケースＢが採用される場合は、実施されなくてよい。

ステップＳ１５１において、共通ＵＲＬリスト生成部２１は、図１１におけるＨＴＴＰ−ＧＥＴのＵＲＬごとに、各試行に含まれる割合（以下、「観測比率」という。）を算出する。
或るＵＲＬの観測比率＝全試行において当該ＵＲＬが観測された回数／試行回数Ｍ
すなわち、観測比率は、１回の試行あたりに観測される回数である。ＵＲＬごとの観測比率の算出結果の一例を図１２に示す。

続いて、共通ＵＲＬリスト生成部２１は、観測比率が、予め設定された共通ＵＲＬ抽出閾値よりも大きいＵＲＬ（共通ＵＲＬ）を抽出し、抽出された共通ＵＲＬのリストである共通ＵＲＬリストを生成する（Ｓ１５２）。生成された共通ＵＲＬリストは、共通ＵＲＬリスト記憶部２６に記憶される。

例えば、共通ＵＲＬ抽出閾値＝０．７とすると、図１３に示されるような共通ＵＲＬリストが生成される。なお、図１３において、ＵＲＬ番号は、各共通ＵＲＬを識別するための識別子である。図１３では、共通ＵＲＬがＣ個である例が示されている。以下におけるＣは、共通ＵＲＬの数を示す。

続いて、共通ＵＲＬ比率算出部２２は、Ｍ回の試行ごとに、当該試行において発生したＨＴＴＰ−ＧＥＴ（図４におけるＨＴＴＰ−ＧＥＴ）の総数に対する共通ＵＲＬの数の比率を算出する（Ｓ１５３）。或る試行に関して、共通ＵＲＬの数とは、当該試行において発生したＨＴＴＰ−ＧＥＴのうち、共通ＵＲＬリストに含まれるいずれかの共通ＵＲＬに一致するＨＴＴＰ−ＧＥＴの数をいう。

続いて、共通ＵＲＬ比率算出部２２は、Ｍ回の試行ごとに、共通ＵＲＬリストに含まれている各共通ＵＲＬについて、当該試行の先頭のＨＴＴＰ−ＧＥＴの発生時刻からの相対値（相対時刻）を算出する（Ｓ１５４）。ここで、共通ＵＲＬリストのうち、当該試行に一致するＵＲＬが含まれている共通ＵＲＬについては、当該ＵＲＬの時刻についての相対時刻が算出される。一方、当該試行に一致するＵＲＬが含まれていない共通ＵＲＬについては、予め設定されている「欠損ＵＲＬ代替時間」が、相対時刻として採用される。また、一つの試行内に同一の共通ＵＲＬが複数回含まれている場合には、予め設定されている「重複ＵＲＬ選定方法」に従って、相対時刻が算出される。例えば、重複ＵＲＬ選定方法において、「最初」の共通ＵＲＬの時刻が選択されることが設定されている場合には、時系列順において最初に出現した共通ＵＲＬの時刻について相対時刻が算出される。また、重複ＵＲＬ選定方法において、「最後」の共通ＵＲＬの時刻が選択されることが設定されている場合には、時系列順において最後に出現した共通ＵＲＬの時刻について相対時刻が算出される。

ステップＳ１５３において算出された共通ＵＲＬ比率、及びステップＳ１５４における算出結果は、各ＨＴＴＰ−ＧＥＴの発生時刻の相対時刻を示すデータ（図７）に追加される。

図１４は、共通ＵＲＬ比率の算出結果及び各共通ＵＲＬの相対時刻の算出結果の一例を示す図である。図１４には、図７に示したデータに加え、共通ＵＲＬ比率及び各共通ＵＲＬの相対時刻が試行ごとに示されている。なお、図１４において、各共通ＵＲＬの相対時刻を示す項目名は、「ＵＲＬ番号−Δｔ」の形式によって表現されている。

続くステップＳ１６０ａは、ケースＢが採用される場合には、第１の実施の形態と同様でよい。一方、ケースＢ以外が採用される場合、推定モデル生成部１３は、学習データ（Ｘ）を以下のように構成する。
Ｘ＝（Ｘ＿１，Ｘ＿２，...，Ｘ＿（Ｎ＋Ｃ））
但し、
Ｘ＿（Ｎ＋Ｃ）＝［０．２２１，３．０００，...，...．，１．１３３］
すなわち、図１４の行列（共通ＵＲＬ比率の列も含む）が、Ｘに代入される。

したがって、ケースＢ以外が採用される場合、ステップＳ１６０ａでは、このような学習データ（Ｘ）が適用されて、第１の実施の形態と同様にモデルＥが生成される。

続くステップＳ１７０ａは、ケースＢが採用される場合は、第１の実施の形態と同様でよい。一方、ケースＢ以外が採用される場合、Ｘ＿ｎｅｗのデータ構造は、図１４の１試行分（１行分）のデータ構造と同じベクトルとなる。この際、共通ＵＲＬ比率は、ネットワーク上で観測されたＨＴＴＰ−ＧＥＴの発生履歴のベクトルと、共通ＵＲＬリスト記憶部２６に記憶されている共通ＵＲＬリストとに基づいて、上記した手順で算出される。また、ネットワーク上で観測されたＨＴＴＰ−ＧＥＴの発生履歴における、各共通ＵＲＬの相対時刻についても、上記した手順で算出される。このようなＸ＿ｎｅｗが適用されて、転送完了時間又は表示完了時間が推定される。

続く、ステップＳ１８０以降は、ケースＡが採用される場合は実行されなくてよい。

ステップＳ１８０において、異常閾値決定部２３は、異常閾値を決定する。異常閾値は、例えば、以下のように決定される。
Ｙ＿ｓｅｌｆｅｓｔｉｍａｔｅ＝Ｅ．ｐｒｅｄｉｃｔ（Ｘ）
として学習データ（Ｘ）による予測結果Ｙ＿ｓｅｌｆｅｓｔｉｍａｔｅを算出し、Ｙ＿ｓｅｌｆｅｓｔｉｍａｔｅのベクトルの要素を数値の大きさで昇順にソートし、ソート結果の下位から「待ち時間異常値カットオフ比率」となる要素の値を、異常閾値とする。なお、学習データ（Ｘ）の値は、ケースＢが採用される場合は、第１の実施の形態において説明した通りであり、ケースＣが採用される場合は、ステップＳ１６０ａにおいて説明した通りである。また、「待ち時間異常値カットオフ比率」は、例えば、分布の下位パーセンタイル指定によって、予め設定される。

なお、異常閾値は、ユーザによって予め設定されてもよい。この場合、ステップＳ１８０は実行されなくてもよい。

続いて、再推定モデル生成部２４は、ステップＳ１７０ａにおける推定結果であるＴ＿ｅが、異常閾値より大きいか否かを判定する（Ｓ１８１）。

Ｔ＿ｅが異常閾値以下である場合（Ｓ１８１でＮｏ）、Ｔ＿ｅが推定結果として確定される。Ｔ＿ｅが異常閾値より大きい場合（Ｓ１８１でＹｅｓ）、再推定モデル生成部２４は、待ち時間が大きい範囲に特化した推定モデル（以下、「モデルＥ２」という。）を生成する（Ｓ１８２）。モデルＥ２の生成に際し、学習データ（Ｙ２）及び学習データ（Ｘ２）が生成される。学習データ（Ｙ２）は、第１の実施の形態において説明した学習データ（Ｙ）から、異常閾値未満の値が除去されたベクトルである。例えば、転送完了時間に関する異常閾値が、２．７であるとすると、図８の（１）において、試行１の２．５は学習データ（Ｙ２）に含まれず、試行２の２．９は学習データ（Ｙ２）に含まれる。

また、学習データ（Ｘ２）には、学習データ（Ｘ）のうち、学習データ（Ｙ２）に含まれる試行に対応した試行に関するデータのみが含まれる。このような学習データ（Ｙ２）及び学習データ（Ｘ２）に基づいて、モデルＥ２の学習が行われる。

第１の実施の形態と同様に、ＳＶＲの機能を持っているscikit-learnのライブラリにおける、ＳＶＲの使い方に準じれば、以下の記述によって、モデルＥ２の生成と、学習とを行うことができる。
E2=SVR() #モデル生成
E2.fit(X2、Y2) #学習データで学習
続いて、再推定部２５は、モデルＥ２を、ステップＳ１７０ａにおいて使用した観測データに対して適用し、当該観測データに関して、転送完了時間又は表示完了時間を推定する（ステップＳ１８３）。
Ｔ＿ｅ'＝Ｅ２．ｐｒｅｄｉｃｔ（Ｘ＿ｎｅｗ）
Ｔ＿ｅ'によって、Ｔ＿ｅが置き換えられる。すなわち、Ｔ＿ｅ'が、推定結果として確定される。

この際、ケースＢ、ケースＣのそれぞれの場合のＸ＿ｎｅｗのデータ構造については、ステップＳ１７０ａにおいて説明した通りである。

なお、第２の実施の形態において、共通ＵＲＬリスト生成部２１は、リスト生成部の一例である。共通ＵＲＬ比率算出部２２は、算出部の一例である。推定モデル生成部１３は、第１のモデル生成部の一例である。推定部１４は、第１の推定部の一例である。再推定モデル生成部２４は、第２のモデル生成部の一例である。再推定部２５は、第２の推定部の一例である。モデルＥは、第１の推定モデルの一例である。モデルＥ２は、第２の推定モデルの一例である。

評価対象ウェブページは、或るウェブページの一例である。転送完了時間及び表示完了時間は、試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータのウェブブラウザへの転送が完了するまでの所要時間の一例である。共通ＵＲＬ抽出閾値は、第１の閾値の一例である。異常閾値は、第２の閾値の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０推定装置
１１学習データ取得部
１２閾値決定部
１３推定モデル生成部
１４推定部
１５学習データ記憶部
２１共通ＵＲＬリスト生成部
２２共通ＵＲＬ比率算出部
２３異常閾値決定部
２４再推定モデル生成部
２５再推定部
２６共通ＵＲＬリスト記憶部
１００ドライブ装置
１０１記録媒体
１０２補助記憶装置
１０３メモリ装置
１０４ＣＰＵ
１０５インタフェース装置
Ｂバス

Claims

ウェブブラウザでのウェブページの表示に関する複数回の試行のそれぞれにおいて観測された所定数のＧＥＴリクエストのＵＲＬのうち、各試行に含まれる割合が第１の閾値以上であるＵＲＬのリストを生成するリスト生成部と、
前記試行ごとに、前記所定数のＧＥＴリクエストのうち、前記リストに含まれるＵＲＬに係るＧＥＴリクエストの比率を算出する算出部と、
前記試行ごとに、前記所定数のＧＥＴリクエストの試行内での相対的な発生時期、前記比率、及び前記リストに含まれる各ＵＲＬに係るＧＥＴリクエストの前記相対的な発生時期を含む情報と、前記試行ごとに計測された、前記ウェブページの表示が指示されてから、少なくとも前記ウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間との関係を、第１の推定モデルに学習させる第１のモデル生成部と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第１の推定モデルを適用して、前記所要時間を推定する第１の推定部と、
を有することを特徴とする推定装置。
前記第１の推定部によって推定された前記所要時間が第２の閾値より大きい場合に、前記複数回の試行のうち、前記所要時間が前記第２の閾値より大きい第１の試行の前記所要時間と、前記第１の試行ごとに、前記所定数のＧＥＴリクエストの前記相対的な発生時期、前記比率、及び前記リストに含まれる各ＵＲＬに係るＧＥＴリクエストの前記相対的な発生時期を含む情報との関係を、第２の推定モデルに学習させる第２のモデル生成部と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第２の推定モデルを適用して、前記所要時間を推定する第２の推定部と、
を有することを特徴とする請求項１記載の推定装置。
ウェブブラウザでのウェブページの表示に関する複数回の試行のそれぞれにおけるに所定数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、前記試行ごとに計測された、前記ウェブページの表示が指示されてから、少なくとも前記ウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間との関係を、第１の推定モデルに学習させる第１のモデル生成部と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に、前記第１の推定モデルを適用して、当該ＧＥＴリクエストに関する前記所要時間を推定する第１の推定部と、
前記第１の推定部によって推定された前記所要時間が第２の閾値より大きい場合に、前記複数回の試行のうち、前記所要時間が前記第２の閾値より大きい第１の試行の前記所要時間と、前記第１の試行ごとの前記所定数のＧＥＴリクエストの前記相対的な発生時期との関係を、第２の推定モデルに学習させる第２のモデル生成部と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第２の推定モデルを適用して、前記所要時間を推定する第２の推定部と、
を有することを特徴とする推定装置。
ウェブブラウザでのウェブページの表示に関する複数回の試行のそれぞれにおいて観測された所定数のＧＥＴリクエストのＵＲＬのうち、各試行に含まれる割合が第１の閾値以上であるＵＲＬのリストを生成するリスト生成手順と、
前記試行ごとに、前記所定数のＧＥＴリクエストのうち、前記リストに含まれるＵＲＬに係るＧＥＴリクエストの比率を算出する算出手順と、
前記試行ごとに、前記所定数のＧＥＴリクエストの試行内での相対的な発生時期、前記比率、及び前記リストに含まれる各ＵＲＬに係るＧＥＴリクエストの前記相対的な発生時期を含む情報と、前記試行ごとに計測された、前記ウェブページの表示が指示されてから、少なくとも前記ウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間との関係を、第１の推定モデルに学習させる第１のモデル生成手順と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第１の推定モデルを適用して、前記所要時間を推定する第１の推定手順と、
をコンピュータが実行することを特徴とする推定方法。
前記第１の推定手順において推定された前記所要時間が第２の閾値より大きい場合に、前記複数回の試行のうち、前記所要時間が前記第２の閾値より大きい第１の試行の前記所要時間と、前記第１の試行ごとに、前記所定数のＧＥＴリクエストの前記相対的な発生時期、前記比率、及び前記リストに含まれる各ＵＲＬに係るＧＥＴリクエストの前記相対的な発生時期を含む情報との関係を、第２の推定モデルに学習させる第２のモデル生成手順と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第２の推定モデルを適用して、前記所要時間を推定する第２の推定手順と、
をコンピュータが実行することを特徴とする請求項４記載の推定方法。
ウェブブラウザでのウェブページの表示に関する複数回の試行のそれぞれにおけるに所定数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、前記試行ごとに計測された、前記ウェブページの表示が指示されてから、少なくとも前記ウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間との関係を、第１の推定モデルに学習させる第１のモデル生成手順と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に、前記第１の推定モデルを適用して、当該ＧＥＴリクエストに関する前記所要時間を推定する第１の推定手順と、
前記第１の推定手順において推定された前記所要時間が第２の閾値より大きい場合に、前記複数回の試行のうち、前記所要時間が前記第２の閾値より大きい第１の試行の前記所要時間と、前記第１の試行ごとの前記所定数のＧＥＴリクエストの前記相対的な発生時期との関係を、第２の推定モデルに学習させる第２のモデル生成手順と、
ネットワーク上において観測された、前記ウェブページに関する各ＧＥＴリクエストの相対的な発生時期に前記第２の推定モデルを適用して、前記所要時間を推定する第２の推定手順と、
をコンピュータが実行することを特徴とする推定方法。