私はかつてソーシャルゲームに関わっていました。そのとき、ソケット通信 (WebSocket 以前の話なので Flash 経由) はそれぞれのユーザーに対して常に開かれていました。500,000人のユーザーが同時にオンラインの状態で、それでも我々のディスパッチサーバー (クライアントとの接続を維持するためサーバー) の CPU 負荷は10%に満たないものでした。そのサーバーは MRI で EventMachine を使って構築されていました。Linux 上では EventMachine は e-poll という Linux の API を利用することができます。それはソケットに対応する IO をスケジューリングするためのものです。これは、Nginx の構成と同じだと言えます。単一のマシン上で数百万のコネクションにまでスケール可能です。(もっと知りたければ、C10k 問題というものをググってみるか、http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html を参照ください) 結論だけ言えば、イベントサーバーはコネクションを維持し管理することに問題はない、ということです。IO へのプッシュはとても簡単です。ただ、1つ問題があるとすれば、ある非常に大きいデータを多くの人が参照したとき、その大きな更新によってネットワーク接続がいっぱいいっぱいになってしまう可能性があります。現在、多くのマシンにまたがる接続や更新の分配を容易にするため、distributed data bus (vert.x と同様のものです) を実装しようとしています。Thin と Goliath の両方のサーバーで、1つの Rack リクエストに対して1つのスレッドが割り当てられますが、すべての WebSocket はシングルスレッドで稼働し、ディスパッチの管理にイベント IO を使います。JRuby では、同様のことを実現するために vert.x と連携したいとも考えています。 上記がいくつかの疑問点に対して回答になれば、と思います。Volt が解決しなければならない困難な問題は多くありますが、コネクションの永続化は問題とはならないと考えています。これは、epoll と O(1) linux scheduler のおかげだと言えます。