目次
ポーリングとは
端末間で更新の監視を周期的に行うこと。
通信を行うほとんどのシステムで実装されている。
実装されているアプリケーションの例：
・Twitterアプリ
・Facebookアプリ
・スマホのメールボックス
等の通知を行うアプリケーション
・分析処理
・集計処理
等の重たい処理を、クライアントの通信対象と別のサーバーで処理を行うアプリケーション
ポーリングの例
今回記載すること
多くの開発者が悩むであろう、ポーリングの間隔（図のX秒のところ）をどのくらいの長さに設定するか考えた。
いくつかのリアルな実装パターン
①とりあえず固定値でｘ秒
一番よくあるのがこのパターン。
いったん一定の秒数に設定しておく。
リクエストが多すぎて処理が遅くなったり、障害が発生したら長い時間にクライアントプログラムを変更する。
また、それほどリソースに負荷がかかっていなければ短い時間にプログラムを変更する。
下記のような状況で、待機時間が想定できない場合に有効である（というか、そうするしかない）
・メール通知など、通知の発生要因が人間のため不定期である
・新しいシステムで、過去の実績が計測ができていない
◎メリット
・リソース次第で爆速でポーリングできる
・実装がお手軽
✗デメリット
・サーバー・ネットワークに負荷がかかりがち
②リクエスト毎に倍加させていく
あまり例が無いが、ntpdプロトコル等に実装されている。
1秒後にリクエスト
2秒後にリクエスト
4秒後にリクエスト
というように、結果が得られるまで徐々に待機時間を増やしてリクエストを行う。
ある程度、結果が得られるまで（＝通知が発生するまで）の時間のばらつきが少ない場合に有効である。
◎メリット
・実測データに基づいて設計すれば、結果が出るタイミングでちょうどリクエストをかけやすい
・実装がお手軽
✗デメリット
・結果が得られるまでの時間の測定値が必要
・サーバー・ネットワークに負荷がかかりがち
③サーバーが動的に決定する
過去のレスポンス速度の実績をサーバーに伝送する方式。
ある程度、結果が得られるまでの時間が、時間帯やレスポンス内容によってばらつきが大きい場合に有効である。
集計処理や分析処理を待つ場合を想定するとわかりやすい。（下記画像参考）
◎メリット
・①に比べ、ポーリング回数が減る
・結果が出るタイミングでちょうどリクエストをかけやすい
✗デメリットとしては、下記が挙げられる
・過去の実績値を取り出しやすい形で蓄積する必要がある（＝KVSやDBに格納する必要がある）
・過去の実績値をリクエスト毎に算出するのでサーバーに負荷がかかる
④クライアントが動的に決定する
こちらは③に対してクライアントが動的にポーリング間隔を決定する方法である。
上記と同様、結果が得られるまでの時間が、時間帯やリクエスト内容によってばらつきが大きい場合に有効である。
◎メリット
③と同じ
✗デメリット
・過去の実績値を取り出しやすい形で蓄積する必要がある（＝localStorageなどに格納する必要がある）
・過去の実績値をリクエスト毎に算出するのでクライアントに負荷がかかる
まとめ
大抵の業務システムは①の実装方式だけど、多分もっと効率的にできるんじゃないかと思って書いた。
①・②の実装方式は作るときは簡単だけど、固定値で秒数を決めるので継続的に監視する必要がある。
③・④ならば、状況に応じて動的に秒数を決めてくれるので、あとあとメンテしなくていい。
③・④はあまり変わらないように見えるが、最近はスマホやPCなどのスペックがどんどん上がっているので、
個人開発をやっているものとしては④のようにサーバーでなく、クライアントに頑張ってもらう方式のほうがいいかなと思ってる
（だいたいサーバーは従量課金なので…）