(57)【要約】【課題】レスポンスが向上したデータ処理プログラム等を提供すること。【解決手段】データ処理プログラムは、クライアントからの第１リクエストを受信するコンピュータに、前記第１リクエスト以降に呼び出される第２リクエストを推定し、前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得し、前記第１リクエストの処理を前記処理データ単位で行い、前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１のリクエストで得た処理で得た処理データ単位に対して前記第２リクエストの処理を行う処理を実行させる。【選択図】図６
2018180959.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの第１リクエストを受信するコンピュータに、
前記第１リクエスト以降に呼び出される第２リクエストを推定し、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得し、
前記第１リクエストの処理を前記処理データ単位で行い、
前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を行う
処理を実行させるデータ処理プログラム。
【請求項２】
第２リクエストと処理データ単位とを対応付けて記憶する記憶部から、推定した前記第２リクエストに対応付けられた処理データ単位を取得する
請求項１に記載のデータ処理プログラム。
【請求項３】
過去に呼び出されたリクエストを記憶する履歴記憶部を用いて、前記第２リクエストの推定を行う
請求項１又は請求項２に記載のデータ処理プログラム。
【請求項４】
クライアントからの第１リクエストを受信する受信部と、
前記第１リクエスト以降に呼び出される第２リクエストを推定する推定部と、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得する取得部と、
前記第１リクエストの処理を前記処理データ単位で実行する単位実行部と
を備え、
前記単位実行部は、前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を実行する
データ処理装置。
【請求項５】
コンピュータが、
クライアントからの第１リクエストを受信し、
前記第１リクエスト以降に呼び出される第２リクエストを推定し、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得し、
前記第１リクエストの処理を前記処理データ単位で実行し、
前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を実行する
処理を実行するデータ処理方法。
【請求項６】
第１リクエスト及び第２リクエストを送信する送信部と、
第１リクエストの処理結果を受信する結果受信部と
を有するクライアント、及び
前記第１リクエスト及び前記第２リクエストを受信するリクエスト受信部と、
前記第１リクエスト以降に呼び出される第２リクエストを推定する推定部と、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得する取得部と、
前記第１リクエストの処理を前記処理データ単位で実行する単位実行部と、
前記単位実行部による前記第１リクエストの処理結果を返却する返却部と
を有するデータ処理装置
を備え、
前記単位実行部は、前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して推定した前記第２リクエストの処理を実行し、
前記結果受信部が前記第１リクエストの処理結果を受信した後に、前記送信部は前記第２リクエストを送信する
データ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＷｅｂＡＰＩ（Ｗｅｂ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を用いるデータ処理プログラムなどに関する。
【背景技術】
【０００２】
近年、ＷｅｂＡＰＩサーバが普及している（特許文献１）。ＷｅｂＡＰＩサーバは、ＷｅｂＡＰＩを実装したサーバコンピュータである。Ｗｅｂ  ＡＰＩは，ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）をベースにデータをやり取りするＡＰＩである。ＨＴＴＰを使った一般的なＷｅｂ  ＡＰＩでは，単純なリクエスト／レスポンスによるデータ交換が行われる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１４６１６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
単純なリクエスト／レスポンスによるデータ交換であるため、複数の処理を連続して行う場合は、レスポンスの低下が生じる。
【０００５】
１つの側面では、本発明の目的は、レスポンスが向上したデータ処理プログラム等を提供することである。
【課題を解決するための手段】
【０００６】
本願に開示するデータ処理プログラムは、クライアントからの第１リクエストを受信するコンピュータに、前記第１リクエスト以降に呼び出される第２リクエストを推定し、前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得し、前記第１リクエストの処理を前記処理データ単位で行い、前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理に基づき、処理可能な最小の行う処理を実行させる。
【発明の効果】
【０００７】
本願の一観点によれば、レスポンスの向上が可能となる。
【図面の簡単な説明】
【０００８】
【図１】データ処理システムの構成を示す説明図である。
【図２】ＷｅｂＡＰＩサーバの構成例を示すブロック図である。
【図３】クライアント端末の構成例を示すブロック図である。
【図４】データ単位ＤＢのレコードレイアウトの一例を示す説明図である。
【図５】履歴ＤＢのレコードレイアウトの一例を示す説明図である。
【図６】ＷｅｂＡＰＩサーバが行う処理の概略を示す説明図である。
【図７】ＷｅｂＡＰＩサーバが行う処理の概略を示す説明図である。
【図８】ＷｅｂＡＰＩサーバが行う処理の手順を示すフローチャートである。
【図９】ＷｅｂＡＰＩサーバの処理において、作成及び更新される一時データの例を示す説明図である。
【図１０】推定処理の手順例を示すフローチャートである。
【図１１】ＷｅｂＡＰＩサーバが備える機能の一例を示すブロック図である。
【発明を実施するための形態】
【０００９】
以下実施の形態を、図面を参照して説明する。なお、以下の説明において、ストリーム処理とは、複数の処理を順次行う処理であって、前段の処理出力が後段の処理入力となる一連の処理、又は一連の処理に含まれる各処理を言う。ここでは、画像データのように、入力データを分割し、分割したデータに対して各処理を行い、分割したデータの処理結果を結合することで、入力データを一括に処理した場合と同じ結果を得られるようなデータを扱う処理を想定している。このような処理の組み合わせをストリーム処理という。
【００１０】
実施の形態１
図１はデータ処理システムの構成を示す説明図である。データ処理システムは、ＷｅｂＡＰＩサーバ（データ処理装置）１、クライアント端末２、及びクライアント端末３を含む。ＷｅｂＡＰＩサーバ１及びクライアント端末２はネットワークＮ１を介して、通信可能に接続されている。ＷｅｂＡＰＩサーバ１及びクライアント端末３は、ネットワークＮ１及び無線ネットワークＮ２を介して、通信可能に接続されている。以下、クライアント端末としては、クライアント端末２について述べるが、クライアント端末３の場合も同様である。
【００１１】
図２はＷｅｂＡＰＩサーバの構成例を示すブロック図である。ＷｅｂＡＰＩサーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１３、大容量記憶部１４、通信部１５及び読み取り部１６を含む。各構成はバスＢで接続されている。
【００１２】
ＣＰＵ１１はＲＯＭ１２に記憶された制御プログラム１Ｐにしたがい、ハードウェア各部を制御する。ＲＡＭ１３は例えばＳＲＡＭ（Ｓｔａｔｉｃ  ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ  ＲＡＭ）又はフラッシュメモリである。ＲＡＭ１３はＣＰＵ１１によるプログラムの実行時に発生するデータを一時的に記憶する。
【００１３】
大容量記憶部１４は、例えばハードディスク又はＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）などである。大容量記憶部１４は必要な各種データを記憶する。大容量記憶部１４はデータ単位ＤＢ（Ｄａｔａ  Ｂａｓｅ）１４１、履歴ＤＢ１４２を記憶する。また、制御プログラム１Ｐを大容量記憶部１４に記憶してもよい。
【００１４】
通信部１５はネットワークＮ１を介して、ＷｅｂＡＰＩサーバと通信を行う。読み取り部１６はＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）−ＲＯＭ及びＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。ＣＰＵ１１が読み取り部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１４に記憶してもよい。また、ネットワークＮ１等を介して他のコンピュータからＣＰＵ１１が制御プログラム１Ｐをダウンロードし、大容量記憶部１４に記憶してもよい。さらにまた、半導体メモリ１ｂから、ＣＰＵ１１が制御プログラム１Ｐを読み込んでもよい。
【００１５】
図３はクライアント端末２の構成例を示すブロック図である。クライアント端末２はＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、大容量記憶部２４、表示部２５、入力部２６、通信部２７及び読み取り部２８を含む。各構成はバスＢで接続されている。
【００１６】
ＣＰＵ２１はＲＯＭ２２に記憶された制御プログラム２Ｐにしたがい、ハードウェア各部を制御する。ＲＡＭ２３は例えばＳＲＡＭ、ＤＲＡＭ又はフラッシュメモリである。ＲＡＭ２３はＣＰＵ２１によるプログラムの実行時に発生するデータを一時的に記憶する。
【００１７】
大容量記憶部２４は、例えばハードディスク又はＳＳＤなどである。大容量記憶部２４はＣＰＵ２１の処理に必要な各種データを記憶する。制御プログラム２Ｐを大容量記憶部２４に記憶してもよい。
【００１８】
表示部２５は液晶表示装置である。表示部２５はデータ処理の結果などを表示する。入力部２６はキーボードやマウスである。また、入力部２６は表示部２５と一体化したタッチパネルでもよい。
【００１９】
通信部２７はネットワークＮ１を介して、ＷｅｂＡＰＩサーバ１と通信を行う。読み取り部２８はＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭを含む可搬型記憶媒体２ａを読み取る。ＣＰＵ２１が読み取り部２８を介して、制御プログラム２Ｐを可搬型記憶媒体２ａより読み取り、大容量記憶部２４に記憶してもよい。また、ネットワークＮ１等を介して他のコンピュータからＣＰＵ２１が制御プログラム２Ｐをダウンロードし、大容量記憶部２４に記憶してもよい。さらにまた、半導体メモリ２ｂから、ＣＰＵ２１が制御プログラム２Ｐを読み込んでもよい。
【００２０】
次に、大容量記憶部２４が記憶するＤＢ（Ｄａｔａ  Ｂａｓｅ：データベース）について説明する。図４はデータ単位ＤＢ１４１のレコードレイアウトの一例を示す説明図である。データ単位ＤＢ１４１はＷｅｂＡＰＩサーバ１が提供する各処理をストリーム処理として実行をする際の処理データの最小単位を記憶する。データ単位ＤＢ１４１は項番列、処理列及び最小データ単位列を含む。項番列はレコードを特定するユニークな項番を記憶する。項番は各処理を特定するＩＤでもある。処理列は処理を特定する処理名を記憶する。最小データ単位列は各処理をストリーム処理する場合の最小のデータ単位（処理データ単位）を記憶する。
【００２１】
図５は履歴ＤＢ１４２のレコードレイアウトの一例を示す説明図である。履歴ＤＢ１４２はＷｅｂＡＰＩサーバが過去に実行した処理の履歴を記憶している。履歴ＤＢ１４２は項番列、アクセス日時列、処理列、入力列及び出力列を含む。項番列は履歴を一意に特定可能な項番を記憶する。アクセス日時列はクライアント端末２から各処理がリクエストされた日時を記憶する。アクセス日時列は各処理の時間的な前後関係を示すものであれば、他のものでもよい。各処理の実行回日時、各処理がクライアント端末２へ処理結果を返却した日時でも良い。処理列は実行した処理を特定する処理名を記憶する。入力列は各処理の入力データを記憶する。出力列は各処理の出力データを記憶する。入力列及び出力列は連続する処理の前後関係が推定可能なものとする。例えば、処理Ａの出力がデータ２であり、処理Ｂの入力がデータ２であれば、処理Ａの次に処理Ｂが実行されたものと推測可能となる。履歴ＤＢ１４２には各処理をリクエストしたクライアント端末２やアプリケーションを特定するＩＤ、例えばＭａｃ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスやセッションＩＤなどを記憶してもよい。それにより、複数のクライアント端末２等が同じ複数の処理を、同時刻にリクエストしたとしても、リクエストの前後関係を正確に把握可能となる。
【００２２】
続いて、ＷｅｂＡＰＩサーバが行う処理について説明する。図６はＷｅｂＡＰＩサーバが行う処理の概略を示す説明図である。図６はクライアント端末２が複数の処理を順次、リクエストした場合を示している。そして、各リクエストに対してクライアント端末２に返却される処理結果をレスポンスとして示している。リクエストは処理、入力データを含む。リクエスト１はデータ１に対して、処理１を行うリクエストである。リクエスト２はデータ２に対して、処理２を行うリクエストである。リクエスト３はデータ３に対して、処理３を行うリクエストである。レスポンスは出力データを含む。レスポンス１の出力データはデータ２である。レスポンス２の出力データはデータ３である。レスポンス３の出力データはデータ４である。図６の示すリクエスト１から３は、前段の出力データが後段の入力データであるストリーム処理である。ＡＰＩ１から３は処理に対応するＡＰＩを示している。ＡＰＩ１は処理１に対応するＡＰＩである。ＡＰＩ２は処理２に対応するＡＰＩである。ＡＰＩ３は処理３に対応するＡＰＩである。リクエストのデータ形式の一例は、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）である。レスポンスのデータ形式の一例は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）やＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ(登録商標）  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）である。
【００２３】
図６に示す例は、ＷｅｂＡＰＩサーバ１が、クライアント端末２から最初のリクエストであるリクエスト１を受けた際に、その後段処理として、処理２及び処理３を推定した例である。そして、その推定が当たった場合である。したがって、最初の入力データ１は最小データ単位に分割され、最小データ単位で処理１が実行されている。処理２及び処理３も分割されたデータ単位で処理されている。また、ＷｅｂＡＰＩサーバ１は推定結果にしたがい、処理２をリクエスト２がされる前に実行を開始している。同様に、ＷｅｂＡＰＩサーバ１は処理３をリクエスト３がされる前に実行を開始している。ＷｅｂＡＰＩサーバ１は、リクエスト２を受け付けた後、処理２に対するレスポンスをクライアント端末２に返している。同様に、ＷｅｂＡＰＩサーバ１は、リクエスト３を受け付けた後、処理３に対するレスポンスをクライアント端末２に返している。処理２及び処理３は先行して実行されているため、リクエスト２及びリクエスト３がリクエストされる前に処理が完了していれば、ＷｅｂＡＰＩサーバ１はリクエストを受けた直後に、レスポンスを返すことが可能である。
【００２４】
図７はＷｅｂＡＰＩサーバ１が行う処理の概略を示す説明図である。図７は図６と同様に、クライアント端末２からＷｅｂＡＰＩサーバ１へのリクエスト、及びリクエストに対しするＷｅｂＡＰＩサーバ１の処理の概略を示している。図７の記載形式は図６と同様である。
【００２５】
図７に示す例は、ＷｅｂＡＰＩサーバ１が、クライアント端末２から最初のリクエストであるリクエスト１を受けた際に、その後段処理として、処理２及び処理３を推定した例である。しかし、その推定が外れた場合である。この場合であっても、最初の入力データ１は最小データ単位に分割され、最小データ単位で処理１が実行されている。推定した後段の処理、処理２及び処理３も分割されたデータ単位で処理されている。また、ＷｅｂＡＰＩサーバ１は推定結果にしたがい、処理２をリクエスト２がされる前に実行を開始している。ＷｅｂＡＰＩサーバ１は分割したデータ１について処理１が完了後、レスポンス１をクライアント端末２に返却している。それに対して、クライアント端末２はリクエスト２ａをＷｅｂＡＰＩサーバ１に送信している。リクエスト２ａに含まれる入力データはデータ２である。リクエスト２ａの入力データがデータ２であるから、リクエスト２はリクエスト１の後段のリクエストである。また、リクエスト２ａに含まれる処理は処理４である。そして、ＷｅｂＡＰＩサーバ１の推定では処理１後の処理は処理２であったため、リクエスト２ａを受信した段階で、推定が外れたことが確定する。
【００２６】
そのため、ＷｅｂＡＰＩサーバ１はすでに開始しているストリーム処理のうち、処理２及び処理３は停止する。ＷｅｂＡＰＩサーバ１は処理１の出力であるデータ２に対して、リクエスト２ａで指定されている処理４を行い、処理４の結果としてデータ４を得る。ＷＥｂＡＰＩサーバ１は出力としてデータ４を含むレスポンス２ａをクライアント端末２に返却する。
【００２７】
次に図６及び７で示した処理の概要をフローチャートにより、処理手順を説明する。図８はＷｅｂＡＰＩサーバ１が行う処理の手順を示すフローチャートである。図８に示す処理は、ＷｅｂＡＰＩサーバ１がクライアント端末２からリクエストを受信する度に実行する。ＷｅｂＡＰＩサーバ１のＣＰＵ１１は受信したリクエストから、処理及びクライアント端末２の端末情報を取得する（ステップＳ１）。端末情報は例えば、クライアント端末２のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレス、ＭＡＣアドレス、認証ＩＤ及びセッションＩＤなどを含む。ＣＰＵ１１はリクエストが最初であるか否かを判定する（ステップＳ２）。最初のリクエストは、ストリーム処理を開始する契機となるリクエストである。最初のリクエストであるか否かの判定は例えば、次のように行う。ＣＰＵ１１はリクエストを送信したクライアント端末２とのセッションが有効であるか否か、クライアント端末２から受信した直前のリクエストの受信日時は所定時間以内か否かなどにより判定する。ＣＰＵ１１はクライアント端末２との間に有効なセッションがなければ最初のリクエストと判定する。ＣＰＵ１１はクライアント端末２との間に有効なセッションがあれば最初のリクエストではないと判定する。また、クライアント端末２から受信した直前のリクエストが所定時間以内、例えば１５分以内の過去であれば、最初のリクエストと判定し、そうでなければ最初のリクエストではないと判定する。
【００２８】
ＣＰＵ１１は受信したリクエストが最初であると判定した場合（ステップＳ２でＹＥＳ）、後段処理の推定を行う（ステップＳ３）。後段処理の推定については後述する。ＣＰＵ１１は推定結果に基づき、ストリーム処理の最小単位を決定する（ステップＳ４）。ＣＰＵ１１は推定結果に基づき、複数の処理を含むストリーム処理を決定する。ＣＰＵ１１はストリーム処理の内容をＲＡＭ１３など設けた一時記憶領域に一時データとして記憶する。ＣＰＵ１１はストリーム処理に含む各処理の最小単位をデータ単位ＤＢ１４１より取得する。ＣＰＵ１１は取得したデータ単位の大小を比較して、最も大きなデータ単位をストリーム処理の最小単位（処理データ単位）とする。ＣＰＵ１１は決定した最小単位で入力データを分割して、分割したデータによりストリーム処理を開始する（ステップＳ５）。ＣＰＵ１１は処理を終了する。
【００２９】
ＣＰＵ１１は受信したリクエストが最初でないと判定した場合（ステップＳ２でＮＯ）、受信したリクエストに含まれる処理がステップＳ３の推定とおりであるか否かを判定する（ステップＳ６）。ＣＰＵ１１は例えば、上述の一時データを用いて、推定とおりか否かの判定を行う。ＣＰＵ１１は処理が推定とおりであると判定した場合（ステップＳ６でＹＥＳ）、ストリーム処理が処理中であるか否かを判定する（ステップＳ７）。ＣＰＵ１１はストリーム処理が処理中でないと判定した場合（ステップＳ７でＮＯ）、処理をステップＳ９に移す。ＣＰＵ１１はストリーム処理が処理中であると判定した場合（ステップＳ７でＹＥＳ）、リクエストに対応する処理が終了したか否かを判定する（ステップＳ８）。ＣＰＵ１１はリクエストに対応する処理が終了していないと判定した場合（ステップＳ８でＮＯ）、ステップＳ８を繰り返し実行し、処理の終了を待つ。ＣＰＵ１１はリクエストに対応する処理が終了していると判定した場合（ステップＳ８でＹＥＳ）、クライアント端末２にレスポンスを送信する（ステップＳ９）。ＣＰＵ１１はストリーム処理が中断されたか否か、又は最後まで処理を終えたか否かを判定する（ステップＳ１０）。ＣＰＵ１１はストリーム処理が中断されていると判定、又は最後まで処理を終えたと判定した場合（ステップＳ１０でＹＥＳ）、上述の一時データを削除する（ステップＳ１１）。ＣＰＵ１１はストリーム処理が中断されてなく、かつ最後まで処理を終えていないと判定した場合（ステップＳ１０でＮＯ）、処理を終了する。
【００３０】
ＣＰＵ１１は処理が推定とおりでないと判定した場合（ステップＳ６でＮＯ）、ストリーム処理が処理中であるか否かを判定する（ステップＳ１２）。ＣＰＵ１１はストリーム処理が処理中でないと判定した場合（ステップ１２でＮＯ）、処理をステップＳ１４に移す。ＣＰＵ１１はストリーム処理が処理中であると判定した場合（ステップＳ１２でＹＥＳ）、ストリーム処理を停止する（ステップＳ１３）。ＣＰＵ１１はリクエストに対応する処理を実行する（ステップＳ１４）。ＣＰＵ１１はステップＳ９以降を実行する。
【００３１】
図９はＷｅｂＡＰＩサーバの処理において、作成及び更新される一時データ２３１の例を示す説明図である。一時データ２３１はクライアントＩＤ２３１ａ及び処理表２３１ｂを含む。処理表２３１ｂは項番列、処理列、入力列、出力列、状況列、及びレスポンス列を含む。項番列は処理の順番を示す番号を記憶する。処理列は処理を特定する処理名を記憶する。処理名ではなく処理ＩＤでもよい。入力列は入力データを記憶する。出力列は出力データを記憶する。状況列は各処理の状況を記憶する。状況とは、例えば、未処理、処理中、又は処理済である。レスポンス列はクライアント端末２に対して、レスポンスを返したか否かを記憶する。例えば、レスポンス列はレスポンスを返していれば「済」を記憶する。レスポンス列はレスポンスを返していなければ「未」を記憶する。
【００３２】
図９に示す例では、最初のリクエストに対する処理が処理１である。その後段として推定した処理が処理２及び処理３である。処理１及び処理２については、分割したすべてのデータに対しての処理が完了している。処理３のみが処理中である。レスポンスは処理１を含むリクエストに対してのレスポンスは済んでいる。この状況において、処理２を含むリクエストを受信した場合、処理２は完了しているので、ＣＰＵ１１はレスポンスを直ちに返すことが可能である。また、処理３を含むリクエストを受信した場合は、処理３の完了を待って、レスポンス返す。さらにまた、この状況において、処理４を含むリクエストを受信した場合、ストリーム処理を停止し、処理２に変えて、処理４を実行する。
【００３３】
続いて、推定処理について説明する。推定処理は図８のステップＳ３で行う処理である。図１０は推定処理の手順例を示すフローチャートである。ＣＰＵ１１は最初のリクエストに含まれる処理を検索対象処理とする（ステップＳ２１）。ＣＰＵ１１は検索対象処理と同一の処理を履歴ＤＢ１４２に対して検索する（ステップＳ２２）。ＣＰＵ１１は検索にヒットした履歴を選択する（ステップＳ２３）。ＣＰＵ１１は選択した履歴の処理の出力データを用い、かつ、履歴の処理とアクセス日時が近い処理（後続の候補処理）を、履歴ＤＢ１４２に対して検索する（ステップＳ２４）。ＣＰＵ１１は検索の結果を一時的に記憶する（ステップＳ２５）。ＣＰＵ１１は未処理の履歴があるか否かを判定する（ステップＳ２６）。ＣＰＵ１１は未処理の履歴があると判定した場合（ステップＳ２６でＹＥＳ）、処理をステップＳ２３へ戻す。ＣＰＵ１１は未処理の履歴がないと判定した場合（ステップＳ２６でＮＯ）、後続の候補処理があるか否かを判定する（ステップＳ２７）。すなわち、ステップＳ２４を繰り返した結果、１つ以上のレコードがヒットしたか否かを判定する。ＣＰＵ１１は候補処理があると判定した場合（ステップＳ２７でＹＥＳ）、候補処理中から１つを推定後続処理として決定する（ステップＳ２８）。ＣＰＵ１１は決定した処理を検索対象の処理とする（ステップＳ２９）。ＣＰＵ１１は処理をステップＳ２２に戻す。ＣＰＵ１１は候補処理がないと判定した場合（ステップＳ２７でＮＯ）、後続の処理がないものとして、処理を終了する。
【００３４】
推定処理の内容を、例を用いて再度説明する。最初のリクエストに含まれる処理が「映像デコード」であるとする。ＣＰＵ１１は検索対象処理を「映像デコード」とする（ステップＳ２１）。ＣＰＵ１１は履歴ＤＢ１４２において、処理列が「映像デコード」であるレコードを検索する（ステップＳ２２）。ＣＰＵ１１は検索結果として、項番１、５、７及びその他の履歴を取得する。ＣＰＵ１１は項番１、５、７及びその他のレコードを順次選択し（ステップＳ２３）、後続となりうる候補処理を検索する（ステップＳ２４）。例えば、項番１のレコードに対しては、項番２のレコードがヒットする。項番５のレコードに対しては、項番６のレコードがヒットする。項番７のレコードに対しては、項番８のレコードがヒットする。検索結果として、ＣＰＵ１１は項番２、６、及び８のレコードを一時的に記憶する（ステップＳ２５）。ＣＰＵ１１はステップＳ２２でヒットしたレコードのうち、未処理のものあれば（ステップＳ２６でＹＥＳ）、ステップＳ２３以降を繰り返す。ＣＰＵ１１はすべてのレコードを処理していれば（ステップＳ２６でＮＯ）、候補処理の有無を判定する（ステップＳ２７）。ここでは、候補処理として、少なくとも項番２、６及び８のレコードが記憶されているので（ステップＳ２７でＹＥＳ）、ＣＰＵ１１はいずれの項番に含まれる処理を後続処理とするかを決定する（ステップＳ２８）。ここでは、「映像デコード」の履歴は項番１、５、７のみしか示していないため、後続処理の決定は困難であるが、他にも履歴が多数あることを前提としている。したがって、「映像デコード」の履歴すべてに対しては、後続の候補処理が多数ある。例えば、ＣＰＵ１１は後続の候補処理の度数を求め、最も度数が大きいものを推定後続処理として決定する。例えば、ＣＰＵ１１は「ノイズ除去」を推定後続処理として決定する。ＣＰＵ１１は「ノイズ除去」を検索対処処理とする（ステップＳ２９）。ＣＰＵ１１はステップＳ２２を実行する。ステップＳ２９の結果、項番２及び８等の履歴レコードがヒットする。ＣＰＵ１１はステップＳ２３以降を行い、さらに後続処理を推定する。ＣＰＵ１１は候補処理がみつからなくなった場合（ステップＳ２７でＮＯ）、推定処理を終了する。なお、後続処理の数が多数となる場合は、途中で足切りをしても良い。例えば、後続の処理は最大１０とし、後続処理の数が１０となった時点で、推定処理を終了する。
【００３５】
本実施形態が奏する効果について説明する。従来、一連のリクエストにより、ＷｅｂＡＰＩサーバが連続処理を行う場合であっても、リクエストに対してレスポンスを返した後、ＷｅｂＡＰＩサーバは後段リクエストの待ち状態となる。すなわち、前段の処理が完了し、次のリクエストが来なければ、後段の処理が実行されない。そのため、例えば、連続した複数の処理を行うことが多い画像処理の場合、スループットの低下が著しくなる。スループットの低下はレスポンスの遅延につながる。
【００３６】
本実施形態のＷｅｂＡＰＩサーバ１はクライアント端末２から最初のリクエストを受けた段階で、後続処理を推定する。ＷｅｂＡＰＩサーバ１は推定結果に基づいて、ストリーム処理としてリクエストを処理する。ストリーム処理に含まれる各処理は後続リクエストよりも先行して実行する。処理が後続リクエストされる前に完了した場合、後続リクエストに対するレスポンス時間は通信時間のみとなる。その結果、スループットを高め、クライアントへのレスポンス速度を向上することが可能となる。ストリーム処理は、特に連続処理の数が多い場合や、データサイズが大きい場合に効果が高くなる。
【００３７】
図１１はＷｅｂＡＰＩサーバが備える機能の一例を示すブロック図である。ＷｅｂＡＰＩサーバ１はリクエスト受信部１１ａ、推定部１１ｂ、取得部１１ｃ、単位実行部１１ｄ及び返却部１１ｅを含む。これらの各機能部は、ＣＰＵ１１が制御プログラム１Ｐに基づいて動作することにより、実現される。
【００３８】
リクエスト受信部１１ａは第１リクエスト及び第２リクエストを受信する。推定部１１ｂは第１リクエスト以降に呼び出される第２リクエストを推定する。取得部１１ｃは第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得する。単位実行部１１ｄは第１リクエストの処理を処理データ単位で実行する。また、単位実行部１１ｄは処理データ単位での第１リクエストの処理が完了する毎に、完了した第１リクエストの処理で得た処理データ単位に対して推定した第２リクエストの処理を実行する。返却部１１ｅは単位実行部１１ｄによる第１リクエストの処理結果を返却する。
【００３９】
各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【００４０】
以上の実施の形態に関し、さらに以下の付記を開示する。
【００４１】
（付記１）
クライアントからの第１リクエストを受信するコンピュータに、
前記第１リクエスト以降に呼び出される第２リクエストを推定し、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得し、
前記第１リクエストの処理を前記処理データ単位で行い、
前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を行う
処理を実行させるデータ処理プログラム。
【００４２】
（付記２）
第２リクエストと処理データ単位とを対応付けて記憶する記憶部から、推定した前記第２リクエストに対応付けられた処理データ単位を取得する
付記１に記載のデータ処理プログラム。
【００４３】
（付記３）
前記第１リクエストに続いて前記クライアントにより呼び出されたリクエストが、推定した前記第２リクエストと異なる場合、推定した前記第２リクエストの処理は中止し、前記呼び出されたリクエストの処理を実行する
付記１又は付記２に記載のデータ処理プログラム。
【００４４】
（付記４）
過去に呼び出されたリクエストを記憶する履歴記憶部を用いて、前記第２リクエストの推定を行う
付記１から付記３のいずれか１つに記載のデータ処理プログラム。
【００４５】
（付記５）
前記履歴記憶部は、呼び出されたリクエストに対応付けて、呼び出された時間、入力データ及び出力データを記憶しており、
２つのリクエストの呼び出された時間の前後を判定し、
前のリクエストの出力データが後のリクエストの入力データである場合に、前のリクエストを第１リクエスト、後のリクエストを第２リクエストとする組データを生成し、
生成した組データより、第１リクエスト毎に対応する第２リクエストの度数を算出し、
度数の最も多い第２リクエストを、第１リクエストに対して推定された第２リクエストとする
付記４に記載のデータ処理プログラム。
【００４６】
（付記６）
前記データ処理単位の全てについて前記第１リクエストの処理が完了した場合、前記第１リクエストの処理結果を前記クライアントに返却する
付記１から付記５のいずれか１つに記載のデータ処理プログラム。
【００４７】
（付記７）
クライアントからの第１リクエストを受信する受信部と、
前記第１リクエスト以降に呼び出される第２リクエストを推定する推定部と、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得する取得部と、
前記第１リクエストの処理を前記処理データ単位で実行する単位実行部と
を備え、
前記単位実行部は、前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を実行する
データ処理装置。
【００４８】
（付記８）
コンピュータが、
クライアントからの第１リクエストを受信し、
前記第１リクエスト以降に呼び出される第２リクエストを推定し、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得し、
前記第１リクエストの処理を前記処理データ単位で実行し、
前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を実行する
処理を実行するデータ処理方法。
【００４９】
（付記９）
第１リクエスト及び第２リクエストを送信する送信部と、
第１リクエストの処理結果を受信する結果受信部と
を有するクライアント、及び
前記第１リクエスト及び前記第２リクエストを受信するリクエスト受信部と、
前記第１リクエスト以降に呼び出される第２リクエストを推定する推定部と、
前記第２リクエストの処理に基づき、処理可能な最小の処理データ単位を取得する取得部と、
前記第１リクエストの処理を前記処理データ単位で実行する単位実行部と、
前記単位実行部による前記第１リクエストの処理結果を返却する返却部と
を有するデータ処理装置
を備え、
前記単位実行部は、前記処理データ単位での前記第１リクエストの処理が完了する毎に、完了した前記第１リクエストの処理で得た処理データ単位に対して前記第２リクエストの処理を実行し、
前記結果受信部が前記第１リクエストの処理結果を受信した後に、前記送信部は前記第２リクエストを送信する
データ処理システム。
【符号の説明】
【００５０】
１        サーバ
１１      ＣＰＵ
１１ａ    リクエスト受信部
１１ｂ    推定部
１１ｃ    取得部
１１ｄ    単位実行部
１１ｅ    返却部
１２      ＲＯＭ
１３      ＲＡＭ
１４      大容量記憶部
１４１    データ単位ＤＢ
１４２    履歴ＤＢ
１５      通信部
１６      読み取り部
１Ｐ      制御プログラム
１ａ      可搬型記憶媒体
１ｂ      半導体メモリ
２、３    クライアント端末
【図１】
2018180959.tif 000003
【図２】
2018180959.tif 000004
【図３】
2018180959.tif 000005
【図４】
2018180959.tif 000006
【図５】
2018180959.tif 000007
【図６】
2018180959.tif 000008
【図７】
2018180959.tif 000009
【図８】
2018180959.tif 000010
【図９】
2018180959.tif 000011
【図１０】
2018180959.tif 000012
【図１１】
2018180959.tif 000013