PlayFrameworkやAkka HTTPでのスレッドプール分割のススメ - Qiita
概要 PlayFrameworkやAkka HTTPをつかっていて、うまくパフォーマンスがでなかった経験ありませんか? もしかしたらそれ、スレッドプールをうまく分割できていなかったからかもしれません。 PlayFrameworkやAkka HTTPなど、ノンブロッキングI/Oを前提につくられたライブラリやフレームワークでは、ブロッキングI/Oに十分な注意を払う必要があります。 具体的に言うと、ノンブロッキングI/Oの処理のみを実行するスレッドプールと、ブロッキングI/O(I/O待ちによりスレッドを占有する)を含む処理を実行するスレッドプールは分割し、それぞれ適切に設定する必要があります。 なぜスレッドプールをわけるか ノンブロッキングI/Oはその特性上、I/O待機中にCPUやスレッドを専有せず、他の処理に割り当てることができます。 この特性を活かし、PlayFrameworkやAkka H
Real World Android Akka - 日本語版
19. 状態を内部に閉じ込めたActorの例 class PlayActor() extends Actor { private val track: AudioTrack = createNewAudioTrack //state. Thread UN-safe override def preStart(): Unit = track.play() override def receive: Receive = { //An actor retrieves and process a message from its mailbox one-at-a-time. case AudioPacketMessage(content:ByteString) => track.write(content.toArray[Byte], 0, content.length) } override d
リアクティブシステムの鼓動(Scala/Akka)
システムの非機能要件は以前より高い要求を求められる傾向にあります。 たとえば、 – より多くのコアを使うには？ – より短い応答時間にするには？ – 限りなく0時間に近いダウンタイムにするには？ – ペタ規模のデータを扱うには？ などと考える機会が増えたと思います。 このような背景で登場したコンセプトが、”レスポンスが速い・障害に強い・負荷に応じてスケールする” 特徴を持つリアクティブシステム(リアクティブプログラミングのことではありません)です。最近注目されているので、言葉だけは耳にしたことがあるのではないでしょうか。クラウドやビッグデータ基盤の進化に合わせてアプリケーション設計の考え方も転換する時期だから注目されているのかもしれません。しかしながら、リアクティブシステムは登場してまだ間もないので、今後に備えてその鼓動を感じてもらえるセッションにしたいと思います。 そして、このリアクティ
Akka 2.4.0がリリースされたのでAkka Persistenceを試してみる。 - Fire and Forget
こんにちは。先月、待望のAkka 2.4.0がリリースされたので、 2.4.0の目玉機能であるAkka Persistenceを試してみました。 いやー、待ちました。なかなかexperimental(実験的な機能の意味)が外れないのでやきもきしていましたが、やっとakka-persistence-experimentalからakka-persistenceになったので、自信を持ってブログで紹介することが出来るようになりました。リリースお疲れ様です！ Akka 2.4.0についてはこちら↓ Akka 2.4.0 Released! | Akka Akka Persistenceについてはこちら↓ Persistence — Akka Documentation 今回の記事は、Akkaは知っているけどAkka Persistenceは知らないよという方向けの記事です。 ん？Elixir？知らな
アクターの諸刃の剣：非同期のメッセージパッシングと状態隔離対障害モデル、そしてそれを克服するAkka Streamの可能性 - TanUkkiiのブログ
ScalaのアクターライブラリであるAkkaでは今までHTTPがIOパッケージでサポートされてきませんでした。HTTPのサポートはAkka Streamの開発とともになされたのです。なぜアクターモデルとHTTPをすぐ統合せずにStreamの登場を待つことになったのか？この疑問に答えることはアクターの問題を考えるよい題材です。 Sprayの革新とその限界 SprayはAkkaのアクターモデルとHTTPを統合して成功したフレームワークです。SprayはJVMベースのフレームワークの中で最高のパフォーマンスを誇りました。SprayはServletがもつがスレッドの高速性と、NodeJSがもつイベントループによる大量のリクエストを効率的に捌くことの特性の両立を、アクターによって可能にしたのです。 ところがSprayはアクターモデルならではの問題とも戦うことになります。Reactive Manife
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
