私もPlay Framework V1.2系を調査しており参考になります。 >>SalesforceやEvernoteなどの外部サービスを実行する場合 play.libs.wsを使えば外部サービスについては非同期化できますよ。 ドキュメントを読むと重い処理のときは Controllerのwaitや、Promiseをつかったりするのが いいようなのですが、いまいち使い方がわからず・・・
コメントありがとうございます。 awaitのあたりのドキュメントやソースはあんまり読んだことありませんでしたが、これ使う場合テンプレートの中からparamsとか参照できなくなるんじゃないですかね?(ThreadLocalに保存されたオブジェクトが置き換わると思うので) 同時に実行できるリクエストが複数あるならwsの非同期Httpリクエストは非常に有効だと思いますが、ほとんどの場合は前のリクエスト結果をうけて次のリクエストが決まるという直線的な処理となることが多いで、それを全部Promiseとawaitでやるのはちょっとめんどくさそうです。 とはいえ、SalesforceのQueryみたいな数秒レベルでブロックするような処理の場合はやっぱりawaitを使うべきなんだろうなと、ちょっと心を入れ替えました。(^^;;;
コメント:Playframeworkとスレッド数
私もplayのデフォルトpool数に疑問を持っていたところで、大変参考になりました。
やはりある程度の数は確保しておく必要がありますよね!(^_^
私もPlay Framework V1.2系を調査しており参考になります。
>>SalesforceやEvernoteなどの外部サービスを実行する場合
play.libs.wsを使えば外部サービスについては非同期化できますよ。
ドキュメントを読むと重い処理のときは
Controllerのwaitや、Promiseをつかったりするのが
いいようなのですが、いまいち使い方がわからず・・・
DBアクセス等の重い処理はJOBに実装して、nowで実行し、
返り値のPromiseをawaitするのがよいようです。
コメントありがとうございます。
awaitのあたりのドキュメントやソースはあんまり読んだことありませんでしたが、これ使う場合テンプレートの中からparamsとか参照できなくなるんじゃないですかね?(ThreadLocalに保存されたオブジェクトが置き換わると思うので)
同時に実行できるリクエストが複数あるならwsの非同期Httpリクエストは非常に有効だと思いますが、ほとんどの場合は前のリクエスト結果をうけて次のリクエストが決まるという直線的な処理となることが多いで、それを全部Promiseとawaitでやるのはちょっとめんどくさそうです。
とはいえ、SalesforceのQueryみたいな数秒レベルでブロックするような処理の場合はやっぱりawaitを使うべきなんだろうなと、ちょっと心を入れ替えました。(^^;;;