Wskaźnik jakości sieci na aplikacji internetowej

Question

Czy istnieje sposób, aby wskazać aktualną jakość sieci klienta (pasek podobny do paska jakości n/w na telefonie) w aplikacji internetowej?

Nasza aplikacja internetowa, która zajmuje się transferem danych, ma większość błędów transferu z powodu problemów z siecią klientów, którzy oczywiście o tym nie wiedzą. Klienci nadal zgłaszają awarie, podczas gdy rzeczywisty problem dotyczy ich n/w łączności i szukam sposobu, który wskazywałby to samo (w mojej aplikacji internetowej) na ich działanie podczas korzystania z aplikacji.

Wiem, że istnieją inne narzędzia do sprawdzenia tego, ale laika użytkownicy nie mają ich (przynajmniej nasi użytkownicy).

Dzięki.

Answer 1

Jednym ze sposobów byłoby użyć window.navigator.onLine na przykład:

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

lub uchwycić zmiany:

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

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

można podjąć średnie pewnych odstępach czasowych i opracowanie algorytmu do ilościowej oceny łączności jako 10%, 50%, itp. ...

Można również ustawić ankietę AJAX i obserwować limity czasu, ale uważaj, aby nie zwiększać ruchu dużo:

$.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

Istnieje kilka założeń do zrobienia w oparciu o sposób przesyłania danych, ilości za jednym razem i częstotliwości.

Zacznę od założenia, że ​​wykonujesz żądania XHR, ponieważ jest to naprawdę jedyny sposób na niezawodny pomiar wymaganych danych.

O ile, mam nadzieję, że nie wysyłasz megabajtów na raz. To sprawia, że ​​trudniej jest zmierzyć czas odpowiedzi (ponieważ warunki sieci mogą się zmieniać w czasie trwania dużego żądania). Ponadto, jeśli użytkownik znajduje się za jakimś proxy, nadmierne żądania mogą zostać odrzucone przez serwer proxy. Przyjmijmy mniej niż 1 MB.

Wreszcie, jeśli przesyłasz dane tylko raz na 5 minut, oczywiście nie będziemy dysponować dużymi danymi pomiarowymi wydajności.

Powiedziawszy to, podchodzę do tego, mierząc całkowity czas żądania dla każdego żądania i licząc liczbę błędów. Coś jak:

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

Będziesz musiał poprawić niektóre z wartości, których użyłem tutaj, głównie na podstawie prób i błędów.

• history to czas (w milisekundach) do utrzymania żądań w średniej ruchomej. Jeśli wysyłasz częste prośby, możesz to wyłączyć. Jeśli wykonujesz tylko jedną prośbę na minutę, być może musisz ją zwiększyć.
• Dowolnie przypisałem całkowitą porażkę jako równoważną 50-sekundowemu czasowi reakcji. Awarie mogą się zdarzyć z wielu powodów, w tym przejściowych problemów z siecią (takich jak słaby sygnał WiFi) i błędów serwera (HTTP 500). Możesz to zmienić w oparciu o testy w rzeczywistych scenariuszach.
• Próbkuję dane czasu odpowiedzi co sekundę.Możesz zrobić to częściej, aby uzyskać bardziej elastyczny miernik sygnału, ale oczywiście będziesz potrzebował więcej cykli procesora, aby to zrobić. Jeśli Twoja aplikacja działa na urządzeniach mobilnych, zachowaj ostrożność.

Będziesz musiał przeprowadzić testy w świecie rzeczywistym, aby określić, jak wygląda średni "dobry" lub "zły" średni czas reakcji.

Answer 3

to sprawdzić http://www.igvita.com/2012/04/04/measuring-site-speed-with-navigation-timing/

To daje wyobrażenie o nowych interfejsów W3c nawigacji taktowania. Chrom/ffox/IE już ma th