さまざまなサーバー ソリューションを評価して、Play2 が Iteratees を使用するとき、特に Websockets リクエストを処理するときに同時実行を処理する方法を理解する必要があります。
共有状態の単純な websocket サーバーを示すこのコード (共同ペイント アプリ) を見ると、https://github.com/gre/playpainter/blob/master/scala/app/controllers/Application.scala
各 Websocket リクエストが、ペインター マップや接続カウンターなどの共有状態を変更する可能性があることがわかります。このコードはスレッドセーフですか? そうである場合 (作成者が確認しました)、同時実行は Play2 によって内部的にどのように処理されますか? 現時点では、残念ながら play2 lib コードを完全に理解するための Scala レベルはありません。
スレッドセーフ（マップまたはカウンターは一度に1つのスレッドでしか変更できない）をどのように調整できるか疑問に思っています（複数のリクエストを「同時に」処理できます）。
私が考えることができる唯一の実行可能な動作は、各 iteratee チャンクの処理を独自のスレッド トランザクション内にラップすることです。(ユーザー コードは単純化されますが) 同時実行性が大幅に制限され、Node.js または任意のシングル スレッド サーバーが提供するものと同様のパフォーマンスが得られるのはどれですか? ストリーミング、ファイル処理などに対する Iteratee プログラミング モデルのメリットはわかりますが、各リクエストが重要な作業 (サーバーの計算、データベース アクセスなど) をトリガーする Websocket ではそれほどではありません。