Playframework の 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
