0

疑似コード:

function getjson() {
   $.getJSON('link_in_my_server_unique_for_each_user_json', function(data) {
     if (data.variable) {
        do_something();
     }
   });​ 
}

setInterval(getjson(), every_second)

毎秒1000人のユーザーがサーバーでjsonファイルを取得し、そのファイルに変数があるかどうかを確認するのは費用がかかりますか?

4

9 に答える 9

21

まず、推測する必要はありません。あなたは測定することができます。

  1. ブラウザで利用可能な開発者ツール（FirefoxのFirebug、Chromeの開発者ツールなど）を使用して、リクエストを監視し、それぞれにかかる時間を確認します。
  2. サーバーの負荷を観察します。0％以外の場合、1000セッションが同時に実行されていることはありません。
  3. 上記の手順を繰り返しますが、多数のブラウザを開いたままにします。20個のブラウザウィンドウを開いて実行するのは簡単なはずです。
  4. サーバーの負荷が50％を超えると、パフォーマンスがますます非線形になることを忘れないでください。システムが大量にブロック/スラッシングすると、クライアントを追加することは期待できません。

ベースライン測定ができたら、最適化について考えることができます-それが必要ですか、そしてあなたはあなたの手にどれほど大きな問題を抱えていますか？通常の解決策のいくつか：

  1. 可能であれば、APCキャッシュから静的ファイルまたはデータの一部を提供します。
  2. データはキャッシュ可能ですが、複数のWebサーバーがある場合は、memcached、MongoDB、またはその他の集中型の非常に高速なキーベースの取得システムなどのソリューションを検討してください。
  3. データがデータベースから動的に取得される場合は、永続的なデータベース接続の使用を検討してください。
  4. リクエストごとのCPU負荷が高い場合は、コードパスに何か高価なものがある可能性があります。特別なコントローラーを手作りして通常のフレームワークをバイパスする必要がある場合でも、その特定のリクエストのコードパスを最適化してみてください。
  5. リクエストごとのネットワーク遅延が高い場合は、HTTPヘッダーを使用して、接続を開いたままにするようにクライアントとサーバーを説得してください。

最後に、必要なパフォーマンスが非常に手が届かないように思われる場合は、アーキテクチャの変更を検討する必要があります。WebSocketを使用すると、コードパスが大きく異なる可能性がありますが、パフォーマンスが大幅に向上する可能性があります。私はあなたが何をしているのかについてもっと知る必要があるでしょうlink_in_my_server_unique_for_each_user_json。

于 2012-10-03T20:25:16.433 に答える
8

はい、これにより、平均的な共有ホスティングまたは小規模な VPS が停止する可能性があります。

このほとんどを CloudFlare や AWS CloudFront などのシステムにオフロードして、キャッシュの有効期限を短く (~1 秒) 設定することは完全に可能です。ほとんどのユーザーはキャッシュから直接取得するため、サーバーの作業のほとんどを節約できます。

于 2012-09-28T15:38:27.497 に答える
6

キャッシュできない場合は、おそらく COMET パターンを検討してください。1 秒間に 1,000 回の呼び出しではなく、1,000 回の長時間保留の呼び出しが発生し、全体的にサービスのトラフィックは少なくなりますが、望ましい結果が得られます。http://en.wikipedia.org/wiki/Comet_%28programming%29を参照してください。

于 2012-09-28T15:41:25.000 に答える
2

Webソケットについて考えましたか

これは、スタック オーバーフローが使用するのと同じ原理です。変数が実際に変更されたときに、データをユーザーにプッシュできます。ただし、そのためにはサーバーを正しくセットアップする必要があります。

于 2012-10-02T15:47:19.333 に答える
1

変数が一意で特定のユーザーに関連していない限り、次の解決策のいずれかをお勧めします。

  • クラウド サービスを使用してキャッシュする
  • Web ソケット接続を使用してユーザーにプッシュする
  • JavaScript を使用してクライアントに作業をオフロードする
  • インターバル ポーリングの代わりにロング ポーリングを使用する

データのポーリングの時代は終わりを告げ、より優れた費用対効果の高いソリューションが存在することがよくあります。

于 2012-10-03T11:25:14.360 に答える
1

したがって、1 秒あたり少なくとも 1,000 リクエストについて話していることになります。これは、強力なマシンであってもかなり高い負荷であると考えられています。では、リクエストごとに何をしなければならないのでしょうか?

  • 接続の初期化
  • リクエストの処理
  • サーバー側ロジックの実行

このシナリオでは、利用可能なすべてのリソース (ファイル I/O を含む) をほとんど消費しています。また、おそらく最も重要な機能ではない付加価値のために、ほとんどの Web サーバー リソースを消費しています。

より良いアプローチは何でしょうか？

変更をポーリングするのではなく、変更に反応したい。したがって、ユーザーごとに、そのイベントを含むチャネルがあり、イベントが発生したときにサーバーから通知を受ける必要があります。残念ながら、別の回答で述べたように、これは PHP の最強のスーツではありません。

クライアント側では、SockJS を見て、それをNode.jsまたはVert.xとペアにすることができます。必要なアーキテクチャはすべて無料で入手でき、セットアップもそれほど難しくありません。SockJS には優れた一連のプロトコル テストも付属しているため、独自のサーバー側実装を非常に簡単に作成できます。

これらの変更により、SockJS プロバイダーへの要求はユーザーごとに 1 つだけになり、必要に応じて個別にスケーリングできます。また、JSON 呼び出しによってプライマリ サービスが中断されることもありません。だから私たちはで終わる

  • SockJS プロバイダーへのページ読み込みごとに 1 つのリクエスト
  • 変更ごとに PHP から SockJS プロバイダーへの 1 つの要求

認証は少し複雑になりますが、PHP アプリケーションと SockJS プロバイダーの両方が知っている秘密鍵を取得し、それを使用して Cookie に署名することができます。次に、JSON リクエストでその Cookie を渡すことができます。

于 2012-09-30T13:17:50.293 に答える
0

ファイルに変数が含まれているかどうかを確認せず、代わりに変数が作成されたことをフロントエンドに通知するのはどうですか？オブザーバーパターンが機能しています！

PHPWebSocketタイプのものを実行できるライブラリがいくつかあります。それらは通常、いくつかの長いポーリングタイプの戦略を含みます。

チェックアウト：http ：//code.google.com/p/phpwebsocket/

于 2012-10-03T01:16:50.020 に答える
0

これは本当に間違った問題を解決しているように見えます。

なぜあなたは、サイトを表示しているすべてのブラウザが毎秒あなたのサイトにアクセスする必要があると感じているのか疑問に思います. たぶん、いくつかのコンテキストが役立つでしょう。

本当にその機能が必要な場合は、はい、それを行うことができます。ただし、それはすべてコストに関するものです。負荷分散された構成で必要な Web サーバーの数を正確に判断するには、それをテストするために話す必要があります。次に、要件を考え出した人に戻り、その「機能」に関連するコストを知らせます。

于 2012-10-05T14:19:13.857 に答える
0

JSON ファイルが「静的な」リクエストである限り (Web サーバーは、リクエストを一部の php/ruby/java/etc. プロセスに渡すことなく、ファイルをそのまま直接提供します)、単純にベンチマークするだけで、サーバーがそれを受け取ることができるかどうかを判断できます。それ。

これは私には事前キャッシュのように見えます (要求される情報はサーバーによって事前に準備され、構造化された応答の形式でキャッシュされます)。これらのタイプのリクエストには nginx を使用してみてください。また、ur ファイルを事前に gzip するためのオプションのモジュールもあります (元のファイルを変更すると、gzip キャッシュが自動的に更新されます)。これにより、追加の CPU (および明らかにより多くの帯域幅) が得られます。

ファイル サイズ、使用可能な帯域幅、CPU の種類、メモリなどを指定しなかったため、「高価ですか?」という質問に対して、誰もあなたに yes/no の答えを与えることはできません。十分な帯域幅 (ファイル サイズに比べて) を備えた堅牢なサーバーでは重要ではないか、共有ホスティングまたは弱い vps セットアップを無効にする可能性があります。

更新:長いキープアライブ (永続的な HTTP TCP 接続) で有効期限ヘッダーを適切に設定すると、HTTP 応答コード 304 Not Modified の恩恵を受けることができます (サーバーは、ファイル全体ではなく、このステータスといくつかのヘッダーのみを提供します)。もう一度）。スクリプトは関与せず、ファイルの提供は関与せず (変更されない限り)、TCP 再接続は行われず、ディスクの読み取りは行われません (ファイルの統計は少なくとも OS によってキャッシュされます) - nginx が raw の最善の策かもしれません静的ファイルのチェック/読み取り/提供のパフォーマンス。

于 2012-09-29T09:43:31.153 に答える