私が気に入っているブラウザはすべて Server Sent Events をほぼ完全にサポートしているので、ポーリングが嫌いで先延ばしにしていたサイトに実装してみたいと思いました。しかし、最初はためらいがあり、何か助けが得られることを望んでいました。
これが私のユースケースです:
ユーザーは、時間ベースで競争力のあるフォーム (この場合はクラス登録) に移動します。すべてが等しい場合、資格のある約30〜40のクラスのリストがあり、「彼女は最初にログインしましたが、最初に保存を押しましたが、保存を押すつもりはありませんでしたが、彼女はすでに選択しました」のインスタンスを最小限に抑えるために別のクラス」など、フォームをリアルタイムで作成したいので、誰かがオプションを選択すると、それがデータベースに直接送られ、フォームを表示している他の人はフォームがいっぱいになっていることがわかります。(気が変わった人のストレスについては後で対処します)。
そのため、ポーリングのシナリオでは、40 個のスポットのステータスを確認して更新し、衝突が発生する可能性がある間隔を設定する必要がある AJAX 呼び出しに対処する必要がありました。
しかし、Server Sent Events を使用すると、更新が必要なスポットだけをリスナーに取得させることができます。
リスナーが過負荷になるリスクはありますか? スクリプトがステータスの変更について連続して 15 個のメッセージを送信するとします。ユーザー エージェントがキューに入れられたタスクを処理する方法について漠然とした言及を目にしますが、それが接続を確立するためなのか、サーバーから送信されたメッセージを処理するためなのかは明確ではありません
これは基本的に、ブラウザからサーバーにポーリングの負担を渡すだけですか? スクリプトは毎秒 DB の変更をチェックする必要がありますか? 変更が発生したときにスクリプトが認識または通知される方法はありますか?
requests.php
シート リクエストがajax 経由で送信されupdates.php
、イベントがブラウザにプッシュされると仮定しましょう。コミットするupdates
までアイドル状態にするための標準的および/または巧妙な方法はありますか?requests
私が考えることができる唯一の解決策はrequests.php
、コミットされた変更をフラット ファイルに書き込み (commits.xml
おそらく)、updates.php
0.5 秒ごとにファイル サイズをポーリングすることで、ワークロードを最小限に抑えることです。
より優れた/よりスマートな/より明白なソリューションはありますか?