アイディア実装してみた。AmazonECSでBatch処理ができるが・・・・もう少し柔軟に行きたいので先読みサーバーを立ててみた。ただプロキシサーバーすると、大量処理している間、クライアントを待たせてしまう。PHPはスレッドが無いのでAWSにバッチで色々一括処理している間ユーザー待ちぼうけ。
そこでQUEUEを入れる。WEB+DB PRESS の過去記事漁ってたらTwistedやPOEもあったのだけれど、どうも今回の用途には向いてない、プロキシサーバーはAWSにリクエストをした後、ユーザーにレスポンスを返し、Flushする。で、コネクションが切れるか切れないかの時に、レスポンスを解析して、先読みREST_URLを作成し、QUEUEに積む。
QUEUEはPEARのNet_Serverをsequentialで立てておいてそこがQUEUEを受け付ける。sequentialでサーバー立てておくとonIdle()イベントが使えるので、暇なときに先読みができる。
これで先読みしてみた。思ったほどパフォーマンスが上がらない。。。。理由は簡単だった。ディスクアクセスを奪い合いするからだ。。。プロキシCGIがキャッシュしながら、メインでユーザー向けCGIが同時動作してる。
WebAPI用のQUEUEサーバーを立てるなら、ディスクは別にするかマシン自体を分割した方が良さそうでした。
ItemSearchしながら、ItemLookupでレビューを先に取得しておくとかできるんだけど・・あと、画像がないときはBK1の画像を探して無理矢理押し込むとかできました。。。
ただ、AWSの規定でResponseデータを改変不可なので、諸刃の刃だけどね。公開Proxyで価格情報を操作されると大変だもんな
