ポーリングだっていいじゃない同盟

ポーリングってダサいイメージがあるけど、ダサいだけなら構わない。ダサい以上のデメリットがあるかどうか考えてみよう。


WebSocketの登場
WebSocketが登場してから、ポーリングダサいってのが特に際立ってきたと思う。だけど、実際にその解説をみると、「これで一つのサーバで100個くらいセッションが維持できちゃうもんね」って書かれてた。もちろんちゃんとパフォーマンスのテストをしてから判断したほうがいいんだろうけど、100個くらいならポーリングでもパフォーマンス的には十分じゃねーかって。

ポーリングの限界ってどう？
結局のところ、ポーリングって、「更新されているかどうかをチェック」することでしかない。システムがやるべきことってこれだけ。

• クライアントは、前回の最終更新日をリクエストパラメータで投げる
• サーバは、サーバ側での最終更新日と比較して、更新されているかどうかのboolean値を返す

以上。更新されていれば、改めてどっかのサーバから本体のコンテンツをダウンロードすればいいから、ポーリングのサーバってコンテンツサーバとは独立していていもいい。スレッドなりデータなりのIDをキーにｍemcacheで保持しているものを、Apacheから参照してやれば、いっくらでもスケールできる。秒間100ってことはない。最低でも数百さばけるだろうし、Webの台数を「普通に」増やすだけでスケールできる。

あとは、あれですね。メッセージアプリの「入力中・・・」みたいなのも、

• ユーザID
• 入力中フラグ

ってキャッシュデータが、入力のイベントのタイミングで作成されて、そのレコードの寿命が２秒くらいだと、「入力中かどうか」ってことが判断が相手から参照できる。マジでこれでシンプルに実装可能。

でも、せいぜい一秒に一回なんでしょ？

後ろめたい？部分があるとすれば、ポーリングはどこまで行っても「リアルタイムに通知されているわけではない」ということ。せいぜい１秒に一回。だけど、試しにポーリングのシステム作ってみなさいよと。１秒に一回でも、平均すると0.5秒の反応。それって人間が感じるリアルタイムとほぼ同じ。

クライアント放置されたら無駄なリクエストが来るじゃない
それはWebScoketを使っていても同じで、無駄なセッションが張られっぱなしになったらリソースの無駄遣い。そしてそもそもWebのサービスを公開している以上は、無駄なGETリクエストには永遠に答えないと行けない。faviconとかね。

そんなわけで、ポーリングで全然OK。素のHTTPのみで実装することで、テストもしやすい。