5

Web アプリケーションでクライアントの現在のネットワーク品質 (電話のネットワーク品質バーに似た何らかのバー) を示す方法はありますか?

データ転送を処理する私たちの Web アプリは、クライアントとのネットワークの問題が原因でほとんどの転送エラーが発生しますが、クライアントは明らかにそれを認識していません。クライアントは失敗を報告し続けますが、実際の問題はネットワーク接続にあり、アプリケーションを使用しているときに (Web アプリ内で) 同じことを示す方法を探しています。

それを調査するための他のツールがあることは知っていますが、素人ユーザーのセットアップにはそれらがありません（少なくとも私たちのユーザー）。

ありがとう。

4

3 に答える 3

2

window.navigator.onLine1 つの方法は、たとえば次のように使用することです。

if (navigator.onLine) {
  alert('online')
} else {
  alert('offline');
}

または変更をキャプチャします。

window.addEventListener("offline", function(e) {
  alert("offline");
}, false);

window.addEventListener("online", function(e) {
  alert("online");
}, false);

特定の時間間隔で平均を取り、接続性を 10%、50% などとして定量化するアルゴリズムを開発できます。

AJAX ポーリングをセットアップしてタイムアウトを監視することもできますが、トラフィックが増えすぎないように注意してください。

$.ajax({
  type: "GET",
  url: "yourserver.com",
  success: function(data){
    alert("Connection active!")
  }
  error: function(XMLHttpRequest, textStatus, errorThrown) {
    if(textStatus == 'timeout') {
       alert('Connection seems dead!');
    }
  }
});
于 2013-01-18T19:46:41.830 に答える
1

ここでは、データを転送する方法、一度に転送する量、および頻度に基づいて、いくつかの仮定を行う必要があります。

XHR リクエストを行っていると仮定することから始めます。これが、必要なメトリックを確実に測定する唯一の方法だからです。

いくらかというと、一度に何メガバイトも送信していないことを願っています。これにより、応答時間の測定が難しくなります (ネットワークの状態は、大きな要求の存続期間中に変化する可能性があるため)。また、ユーザーが何らかのプロキシの背後にいる場合、特大のリクエストがプロキシによって破棄される可能性があります。1 MB 未満と仮定しましょう。

最後に、データを 5 分ごとに 1 回しか送信しない場合は、処理するパフォーマンス測定データがあまりないことは明らかです。

そうは言っても、各リクエストの合計リクエスト時間を測定し、失敗の数を数えることでこれに取り組みます。何かのようなもの：

var recentResults = [], history = 90000;
function sendData() {
    var start = Date.now(); // remember when we started this request
    $.post('/some/api', { some: 'data' }, function(r) {
        recentResults.push({start:start, end:Date.now() - start}); // record how long it took (ms)
    }).fail(function() {
        recentResults.push({start:start, end:null}); // record a failure
    });
}

setInterval(function() {
    var now = Date.now();
    if (recentResults.length > 0) while (now - recentResults[0].start > history) {
        recentResults.shift(); // prune old data
    }


    var sum;
    for (var i = 0, r; i < recentResults.length; r=recentResults[i++]) {
        if (r.end == null) sum += 50000;
        else sum += r.end;
    }

    var movingAverage = sum / recentResults.length;

    // use movingAverage to calculate the overall connection quality

}, 1000);

ここで使用した値のいくつかは、主に試行錯誤に基づいて微調整する必要があります。

  • historyリクエストを移動平均に保持する時間 (ミリ秒単位) です。頻繁にリクエストする場合は、これを断ることができます。1 分間に 1 つのリクエストのみを行っている場合は、それを増やす必要があるかもしれません。
  • 完全な失敗を 50 秒の応答時間に相当するものとして任意に割り当てました。障害は、一時的なネットワークの問題 (WiFi 信号の低下など) やサーバー エラー (HTTP 500) など、さまざまな理由で発生する可能性があります。実際のシナリオでのテストに基づいて、これを調整することができます。
  • 応答時間データを毎秒サンプリングしています。信号メーターの応答性を高めるために、これをより頻繁に行うことができますが、これを行うには明らかにより多くの CPU サイクルが消費されます。アプリをモバイル デバイスで実行する場合は、十分に注意してください。

「良い」平均応答時間と「悪い」平均応答時間がどのように見えるかを判断するには、実際のテストを行う必要があります。

于 2013-01-19T01:43:08.427 に答える
0

これをチェックしてください http://www.igvita.com/2012/04/04/measuring-site-speed-with-navigation-timing/

これにより、新しい W3c Navigation タイミング インターフェイスについてのアイデアが得られます。Chrome/ffox/IE にはすでに th があります

于 2013-02-08T19:00:49.693 に答える