websocketsのpipeline
またもEmerge Technologyからのネタ。
この、websocket pipelineのサンプルが意味するところら辺の話。
# ちなみにHTML5のドラフト上、「websocket」ではなく「websockets」が正解・・・だったと思うw
websocketsの利用シーンとしては現状httpでは出来ないサーバ側からの通知とか、
非同期通信ばかりを思い浮かべていたけど、ajaxで出来る事もwebsockets化する！って
言うのはなんと言うか着眼点が面白いというかちょっと思いつかなかったなぁと言う感じ。
ただ、なんと言うか記事読んでいて思ったのは、
「websockets+pipelineが凄い！」っていう結論に成るような論旨展開に成っているんじゃない？！という事。
pipelineにするとシーケンシャルにしか処理できません。
例えば、１件処理するのに３秒かかるリクエストを３件行うとします。
３並列で実行すれば３秒、シーケンシャルに処理すれば３秒x３＝９秒かかるのは当たり前です。
ただ、この話は３並列で処理を実行した場合のオーバーヘッドが０という前提が必要です。
それをふまえ、何故、「websocket+pipeline」のサンプルがajaxでの処理が遅いのか考えてみると、
サーバ側でリクエスト１件に対するオーバーヘッドが大きいからに他成りません。
mod_python使っていても、handlerがpublisherの場合のTPSはそんなに良くないはずです。
またサーバ側のCPUのスレッド数も分かりませんし、
apacheのpreforkがいくつに成っているのかも分かりません。
websockets版はスレッドとしてpython上でread/writeをループしているだけで、
pythonの初期化とかしてないので早くて当たり前ですね。
上記のような事を考察せずNWの遅延とかターンアラウンドの話ばかりを引き合いに出しているあたり、
微妙に突っ込まれる事も有るかも知れません。
その上WebSocketsの方はページを開いたときにコネクションを張ってしまっています。
なんと言うか、インフラとかapacheとかajaxに詳しくない人って印象を受けてしまうのは気のせいでしょうか。
穿って考えると、websocket+pipelineが早い、という事ではなく、
「自分のサーバとかJSだとwebsockets+pipelineの方が早いみたい。」
と、言う話で一般的にAjaxよりもwebsockets+pipelineが早いという話では無いような気がしてきます。
と、色々書きましたがやっぱりWebSocketsは現状httpでは出来ない事を実装するためのものと、
思った方が良いのかも。
http(s)なら今までの資産として、javascriptのライブラリも使えるし、
cookieとか認証とか文字コード変換とかjsonとかproxyでのキャッシュとか
今まで蓄積してきたモノが使えます。
websockets上で独自プロトコル作るのがデファクトとは思えず。
まー、apache + mod_pythonなんてケチな環境じゃなく、
golangで専用プロセス上げてればもうちょっと違う結果になったのかもw