Indicatore della qualità della rete su un'app Web

Question

C'è un modo per indicare la qualità corrente della rete del client (una barra di qualche tipo, simile alla barra di qualità n/w su un telefono) su un'applicazione Web?

Una nostra web app, che si occupa di trasferimento dati, ha la maggior parte dei fallimenti di trasferimento a causa di problemi di rete con i clienti, che ovviamente non ne sono a conoscenza. I client continuano a segnalare errori mentre il problema reale riguarda la connettività n/w e sto cercando un modo che possa indicare lo stesso (all'interno della mia app Web) quando utilizzano l'applicazione.

So che ci sono altri strumenti per indagare su questo, ma le configurazioni utente non interattive non ne hanno (almeno i nostri utenti).

Grazie.

Answer 1

Un modo potrebbe essere quello di utilizzare window.navigator.onLine ad esempio:

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

o catturare il cambiamento:

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

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

si potrebbe prendere in media su determinati intervalli di tempo e sviluppare un algoritmo per quantificare la connettività come 10%, 50%, ecc ...

Si potrebbe anche solo impostare un sondaggio AJAX e guardare per i timeout, ma attenzione a non aumentare il traffico troppo molto:

$.ajax({ 
    type: "GET", 
    url: "yourserver.com", 
    success: function(data){ 
    alert("Connection active!") 
    } 
    error: function(XMLHttpRequest, textStatus, errorThrown) { 
    if(textStatus == 'timeout') { 
     alert('Connection seems dead!'); 
    } 
    } 
}); 

Answer 2

Ci sono alcune ipotesi di fare qui in base a come si trasferiscono i dati, quanto alla volta, e con quale frequenza.

Inizierò assumendo che tu stia facendo richieste XHR, perché questo è davvero l'unico modo per misurare in modo affidabile le metriche di cui abbiamo bisogno.

Per quanto, spero che non invii megabyte alla volta. Ciò rende più difficile misurare il tempo di risposta (poiché le condizioni della rete possono variare nel corso della vita di una richiesta di grandi dimensioni). Inoltre, se un utente è dietro qualche tipo di proxy, le richieste di grandi dimensioni potrebbero essere sballottate dal proxy. Supponiamo meno di 1 MB.

Infine, se invii solo dati una volta ogni 5 minuti, ovviamente non avremo molti dati di misurazione delle prestazioni con cui lavorare.

Con ciò detto, mi avvicinerei a questo misurando il tempo di richiesta totale per ogni richiesta e contando il numero di guasti. Qualcosa di simile:

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); 

Dovrai modificare molti dei valori che ho usato qui principalmente per tentativi ed errori.

• history è il periodo di tempo (in millisecondi) per mantenere le richieste nella media mobile. Se stai facendo richieste frequenti, puoi disattivarlo. Se stai facendo una sola richiesta al minuto, potrebbe essere necessario aumentarla.
• Ho arbitrariamente assegnato un errore completo come equivalente a un tempo di risposta di 50 secondi. I guasti possono verificarsi per qualsiasi numero di motivi, inclusi problemi di rete transitoria (come un segnale WiFi scarso) e errori del server (HTTP 500). Si consiglia di regolare questo in base ai test in scenari reali.
• Sto campionando i dati del tempo di risposta ogni secondo.Puoi farlo più frequentemente per un misuratore di segnale più reattivo, ma ovviamente dovrai consumare più cicli della CPU per farlo. Se la tua app funziona su dispositivi mobili, stai molto attento.

Dovrai eseguire test nel mondo reale per determinare l'aspetto di un tempo di risposta medio "buono" o "cattivo".

Answer 3

check this out http://www.igvita.com/2012/04/04/measuring-site-speed-with-navigation-timing/

Questo dà un'idea di nuove interfacce di temporizzazione W3c navigazione. Chrome/ffox/IE ha già