■課題
cronでの定期実行だと1分間が最短になるけど、cronの実行誤差で抜ける現象が発生した。
本来欲しいデータ:
2011-03-30 19:59:55 84.5
2011-03-30 20:00:55 84.3
実際のデータ:
2011-03-30 19:59:55 84.5
2011-03-30 20:01:03 84.5
スポットレートの抜けよりも毎時00分に実行される60分足が作成されなくなってしまうのが一番の問題。
■対策1
レート取得タイミングを2重化して実行誤差を吸収する方法。
結局、キーがMIまでなので、20:00:05も20:00:55も同じ20:00のキーとなるため、第1案はcronを2重化して実行誤差によるレート取得タイミングをそれぞれずらす。
問題:
cronを2重化するため、リクエスト数が2倍。併せてCPU Timeも2倍になる。
■対策2
60分足の作成を毎時00分ではなく、スポットレート取得タイミングで随時更新していく。
スポットレートよりも60分足の優先度が高いため、60分足開始時刻から終了時刻までcron実行タイミング(1分間隔)で60分足のデータを更新する。
問題:
データストアへのアクセスが増大する。
従来:
Model.get() 720回(=60分*12ペア)
Model.put() 12回(=12ペア)
対応後:
Model.get() 720回(12ペア*60分)
Model.put() 720回(12ペア*60分)
■結論
個人的には対策2がいいように思う。
問題は60分足。CPU Timeはたしかに増大するが、(1)60分足が確実に取れる、(2)リアルタイムで60分足が伸び縮みする点がメリットかと思う。
という訳でロジックの変更になる。
cronでの定期実行だと1分間が最短になるけど、cronの実行誤差で抜ける現象が発生した。
本来欲しいデータ:
2011-03-30 19:59:55 84.5
2011-03-30 20:00:55 84.3
実際のデータ:
2011-03-30 19:59:55 84.5
2011-03-30 20:01:03 84.5
スポットレートの抜けよりも毎時00分に実行される60分足が作成されなくなってしまうのが一番の問題。
■対策1
レート取得タイミングを2重化して実行誤差を吸収する方法。
結局、キーがMIまでなので、20:00:05も20:00:55も同じ20:00のキーとなるため、第1案はcronを2重化して実行誤差によるレート取得タイミングをそれぞれずらす。
問題:
cronを2重化するため、リクエスト数が2倍。併せてCPU Timeも2倍になる。
■対策2
60分足の作成を毎時00分ではなく、スポットレート取得タイミングで随時更新していく。
スポットレートよりも60分足の優先度が高いため、60分足開始時刻から終了時刻までcron実行タイミング(1分間隔)で60分足のデータを更新する。
問題:
データストアへのアクセスが増大する。
従来:
Model.get() 720回(=60分*12ペア)
Model.put() 12回(=12ペア)
対応後:
Model.get() 720回(12ペア*60分)
Model.put() 720回(12ペア*60分)
■結論
個人的には対策2がいいように思う。
問題は60分足。CPU Timeはたしかに増大するが、(1)60分足が確実に取れる、(2)リアルタイムで60分足が伸び縮みする点がメリットかと思う。
という訳でロジックの変更になる。
コメント
コメントを投稿