WebSocketとかChannelとか

GAEのChannelは、無料枠では1日100オープンまでだし、HerokuのWebSocket(Pusher)は無料枠で20コネクションまでだし、リアルタイム性の高いPush通信は、コストが高くついて困るなあなんて話を過去のエントリでしたわけですが、

考えてみると、Push It!は、通信対戦アクションゲームのようなギチギチのリアルタイム性を求めているわけでなく、数秒程度の遅延で付箋が更新されれば良くって、だったらChannelやWebSocketである必要なくね？と思い返した。

ただ、短周期のポーリングは避けたいね、クライアントにもサーバにもネットワークにも負荷だし、というのがそもそもChannelやWebSocketを使おうとしたそもそもの理由。

ってことは、Long Pollingでいいんじゃね？という気がした。

GAE/Python2.5だと、CPUすかすかでも１リクエストが１インスタンスを占有するから現実的ではないのだが、GAE/Python2.7（か、Java）だったらマルチスレッド対応なので、CPUすかすかなら対応できるかもしれない。

ただ、GAE/P（多分Jもだが）、リクエスト処理中に外部からのイベントを受け付けられる仕組みにはなってないので、更新があったかどうか、内部では短周期でポーリング（Datastoreなりmemcacheなりに対して）してあげないといけない。これがネック。

HerokuだとNode.jsが使えるので、外部からのイベントが来るまでリクエスト処理は放置しておけるんじゃないか？だとしたら、Long Pollingがかなりラクかつ低負荷で実施できそうな気もする。
どうなんだろ。試してみたい。