6

私は次のような非常に単純な長いポーリングajax呼び出しを持っています：

(function poll(){
    $.ajax({ url: "myserver", success: function(data){
        //do my stuff here

    }, dataType: "json", complete: poll, timeout: 30000 });
})();

私は今日の午後にこの例を取り上げましたが、うまく機能しているようです。私はそれを使って自分のページにいくつかのhtmlを作成していますが、それは私が知る限りほぼ瞬時に行われます。これによりサーバー上でワーカースレッドが開いたままになり、サーバーの負荷が大きすぎると完全に停止するのではないかと少し心配しています。誰かがこの理論に光を当てることができますか？バックエンドには、データベースを呼び出してオブジェクトをビルドし、オブジェクトを元に戻すwebapiサービス（.net mvc 4）があります。また、これが機能するためには、サーバーがデータベースを絶えず呼び出す必要があるように思われます...そしてそれは適切ではありませんか？

次の質問は、自分のページのhtmlを更新する必要があるかどうかをクライアントが判断するための最良の方法は何ですか？現在、JSON.stringify（）を使用してオブジェクトを文字列に変換し、古い文字列に到達する文字列を比較しています。デルタがある場合は、ページ上のhtmlが再書き込みされます。現在、全体はありません。ダウンするオブジェクトの多くがダウンしますが、それは潜在的に非常に大きくなる可能性があり、その文字列比較を行うことは、クライアントにとってかなりリソースを消費する可能性があると思います...特にそれがほぼ常に行われている場合。

私にとっての結論は次のとおりです。ポーリングがどのくらいの期間機能するか正確にはわかりません。グーグルで検索し、上記のサンプルコードを見つけて実装しました。表面的には、すばらしいです。問題が発生するのではないかと心配しています。 （サーバー上で）ダウンし、古い結果を新しい結果と比較する私の方法は、（クライアント上で）悪意を持って行き詰まります。

あなたが提供できるありとあらゆる情報は大歓迎です。

TIA。

4

2 に答える 2

13

OK、私の2セント：

  1. 他の人が言ったように、SignalRはコードを試し、テストしたので、自分で書く代わりにそれを使用することを本当に検討したいと思います。
  2. SignalRは、この種の作業のためにIISを最適化するために、IIS設定の一部を変更します。したがって、独自の実装を検討している場合は、SignalRで行われたIIS設定の変更を確認してください。
  3. サーバーが何らかの形式のサーバープッシュを実装できるように、長いポーリングを行っていると思います。これにより、ステートレスHTTPマシンがステートフルマシンに変わり、スケーリングする場合は適切ではないことに注意してください。ロードバランサーの背後での長いポーリングは良くありません:)私にとって、これはサーバープッシュの最悪のことです。
  4. ASP.NETは、要求を処理するためにThreadPoolを使用します。長いポーリングはThreadPoolスレッドを占有します。これらのスレッドが多すぎると、スレッドが不足する（そして涙が出る）可能性があります。球場の数字として、100は多すぎませんが、+1000は多すぎます。
  5. SignalRチームでさえ、SingalR用に最適化されたIISボックスは、おそらく通常のASP.NET用には最適化されていないと述べており、これらのボックスを分離することをお勧めします。つまり、これはコストとオーバーヘッドを意味します。

結局のところ、ビジネス上の問題を解決する場合は（クールだからではなく）、長いポーリングを使用することをお勧めします。そうすると、コストとオーバーヘッドと頭痛の種が増えるからです。

于 2012-12-17T13:46:51.450 に答える
10

SLaksに同意します。つまり、WebApi http://www.asp.net/signalrでリアルタイムWebが必要な場合は、SignalRを使用します。長いポーリングをうまく実装するのは難しいので、他の誰かにその複雑さを処理させてください。つまり、SignalR（WebApiの自然な選択）またはCometを使用してください。

SignalRは、長いポーリング、Webソケット、サーバー送信イベント、および永久フレーム（ここ）に頼る前に、他の3つの形式の通信を試みます。

状況によっては、単純なポーリング、つまり1秒ごとにヒットして更新する方がよい場合があります...この記事を参照してください。しかし、ここに引用があります：

メッセージの量が多い場合、ロングポーリングでは、従来のポーリングに比べてパフォーマンスが大幅に向上することはありません。実際、それはさらに悪いことかもしれません。なぜなら、長いポーリングが制御不能になり、スロットルされていない、即時のポーリングの連続ループになる可能性があるからです。

恐れは、Webページに大きな負荷がかかると、30秒のajaxクエリが最終的にサービス拒否攻撃になる可能性があることです。

Bayeux（CometD ）でさえ、負荷が大きくなりすぎると単純なポーリングに頼ります。

サーバーの負荷の増加とリソースの不足は、再接続と間隔のアドバイスフィールドを使用してクライアントを調整することで対処されます。これは、最悪の場合、従来のポーリング動作に低下します。

あなたの質問の2番目の部分については。

長いポーリングを使用している場合、サーバーは理想的には何かが実際に変更された場合にのみ更新を返す必要があります。したがって、UIはおそらく応答を「信頼」し、応答が新しいデータを意味すると想定する必要があります。同じことがサーバープッシュタイプのアプローチにも当てはまります。

単純なポーリングpullmethodに戻った場合は、組み込みのhttpメソッドを使用して、If-Modified-Sinceヘッダーを使用して更新を検出できます。これにより、304 Not Modifiedを返すことができるため、サーバーはオブジェクトであり、最後のリクエスト以降に変更された場合にのみ、オブジェクトとともに200を返します。

于 2012-12-17T09:10:46.350 に答える