私は40,000のデスクトップにインストールされるブラウザプラグインを持っています。
このプラグインはhttpsで利用可能なバックエンド設定ファイルに接続します。 http://somesite/config_file.js。これはWebSocketを使用する正しいシナリオですか？
プラグインはこのバックエンドリソースを1日1回ポーリングするように設定されています。 しかし、バックエンドサーバーは1つだけです。したがって、40,000のエンドポイントが一緒にポーリングを開始すると、サーバーがクラッシュする可能性があります。 デスクトップのプラグインからポーリングの狂気をランダム化すると思います。しかし、ランダム化は、サーバに過負荷がないことを保証するものではありません。
この場合、websocketを使用してスケーラビリティの問題を解決していますか？
1日に1回のポーリングはごくわずかです。
プッシュに切り替えて通知を受け取っていない限り、Websocketのメリットはありません。
しかし、同じ時間に要求を同期すると、自分のサーバーに対してDoS攻撃を行うようなので、ポーリングをずらすことは非常に意味があります。
偶然がランダムである必要はなく、IMHOである必要はありません。
固定時間で開始し、クライアントIDごとに秒を追加すると、24時間以内に〜86K接続が可能になり、どのサーバーでも簡単に処理できます。
40Kの同時接続は想像以上に難しくありません。 （コメントに関連する）
EDITサーバー送信されたイベント対
WebSocketを：
IMHO、（ポーリング対）データをプッシュするとき、私はオーバーWebSocketをを好むだろうサーバー送信イベント（SSE）。
ウェブソケットには、クライアント側の通信のようにクライアントにpingのサーバーを接続し、接続がまだ生きていることを確認するなど、いくつかの利点があります。
具体的なユースケース：
問題の説明と、あなたがカスタムプラグインでブラウザクライアントを使用していることを、あなたが毎日インストールしたいのアップデートブラウザを必要とするかもしれないと思われるコメントからアクティブにする。
これは実装に影響するさまざまな質問を引き起こします（クライアントブラウザは一日中開いていますか？クライアントブラウザとその環境を制御できますか？ブラウザが閉じている間はインストールを保証できますか？
...
私見では、あなたは彼らがその日（最初のアクセス）の際に初めてロードすると、毎朝更新のクライアントプラグインのテストを持っ考えるかもしれません。
人はさまざまな時代に仕事に就き、さまざまなスケジュールで初めてブラウザを開きます。したがって、あなたが期待している40Kのリクエストは、そのタイムライン（おそらく20〜30分のタイムスパン）に自然に散らばります。
この方法では、ブラウザとコンピュータが実際に開いている（アップデートが可能）ことを確認し、ある一定の期間（私の前提が正しい場合は約33.3要求/秒）
動的コンテンツを避け、データベース呼び出しを最小限に抑えるために、事前に書かれた静的構成ファイルを（毎日サーバーによって更新されて）提供している場合は、33 req/secよりも管理が簡単です。
興味深い点があります。私はwebsocketがこのシナリオには適していないと思います。おそらく、サーバー側のイベントがより良い代替アプローチになる可能性があります。これはクライアントに更新をプッシュできます。 –
IMHO、SSEはウェブソケットの貧弱な代替品です。プッシュを実装する場合は、確実にウェブソケットを使用してください。しかし、1日に1回到着し緊急ではないアップデートの場合、プッシュは過度の攻撃のように見えます。更新要求が割り当てられた更新期間に均等に分散され、サーバーに負荷がかかっていない限り、cronジョブの実装はずっと簡単です。 – Myst
それはそれより少し複雑です。プラグインはローカルブラウザにインストールされるため、これらのプラグインがインストールされた後でこれらのプラグインを制御することはできません。どのようにcronjobを使用して実装することをお勧めしますか？多分私はポイントを取得していないでしょう。私は、各コンピュータのIPアドレスからユニークなハッシュ値を取得し、それを使って各プラグインからの固有のポーリング時間を計算しようとします。それには欠点があります（すべてのユーザーがすぐに更新プログラムを入手するわけではありません）が、間違いなくすべてのプラグインを同時にサーバーに適用することはできません。 –