読者です 読者をやめる 読者になる 読者になる

謎言語使いの徒然

適当に気になった技術や言語を流すブログ。

Playframework の Akka 設定を読み解く

Playframework Scala Tips Akka

※ Play2.0.3 時代の古いやつです
Playframework は Akka を利用しており、性能に直結してる。
もし、CPUやメモリに余裕があり、更に大規模なアクセスに対応したい場合は、設定を上書きできる。

application.conf で設定可能だが、Playのデフォルト設定は下記である

play {
    akka {
        event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
        loglevel = WARNING
        actor {
            deployment {
                // Akka コントローラ処理を実行するActor設定(デフォルト24個のアクターをラウンドロビンで使いまわし)
                /actions {
                    router = round-robin
                    nr-of-instances = 24
                }

                // タイムアウトまでに応答が完了できない場合のストリーミング処理に使うActor設定
                /promises {
                    router = round-robin
                    nr-of-instances = 24
                }
            }

            // この時間以内にActionが完了してないと、タイムアウト扱い
            retrieveBodyParserTimeout = 1 second

            // サーバから発生したリクエストを捌いてactionアクターに処理を与える設定
            actions-dispatcher = {
                fork-join-executor {
                    parallelism-factor = 1.0
                    parallelism-max = 24
                }
            }
            promises-dispatcher = {
                fork-join-executor {
                    parallelism-factor = 1.0
                    parallelism-max = 24
                }
            }
            websockets-dispatcher = {
                fork-join-executor {
                    parallelism-factor = 1.0
                    parallelism-max = 24
                }
            }
            default-dispatcher = {
                fork-join-executor {
                    parallelism-factor = 1.0
                    parallelism-max = 24
                }
            }
        }
    }
}

deployment 内は実際に処理を行うインスタンスとそのスレッド数、及び、処理を振り分ける方式を指定している。

akka の説明になるが、akka の登場人物は下記のものがある

  • ActorRef : 下記の要素を内包する外見えのActor
    • dispatcher : メッセージを mailbox に格納し、Actor に処理を促す
    • mailbox : 受け取った処理要求を「message」として格納しておくキュー領域
    • Actor : dispatcher に叩かれると、mailbox から message を1件づつ処理する処理の本体

ここから下は推測が混じってます。どれくらい混じってるかは注釈入りです。
断片的な情報しか拾えなかったという。*1

dispatcher 設定の fork-join-executor は parallelism-max で指定したスレッドをActorに与えて実行する方法。使い終わったらスレッド尾から Actor を引きはがす。必要に応じて、スレッドを増減させながら処理を回します。*2
thread-pool-executor というのもあって、こちらはActorごとに専用のスレッドを用意するパターン。*3Actor へのスレッド割り当てがない分オーバーヘッドはないですが、スレッドが解放されることもないのでメモリを食います。*4

*1:知ってる人がいたら是非教えていただきたい

*2:多分この挙動は間違ってない

*3:ここまでは間違ってない筈

*4:ここは推測。保障できない