Rebuffering

Panoramica

Il rebuffering è il star nord di Microsoft eCDN per valutare la qualità dell'esperienza di visualizzazione.

Definizione

Il rebuffering è definito come qualsiasi periodo di tempo durante il quale un visualizzatore trascorre il buffering con un video fermo o nessun video. Viene calcolato per singolo utente come percentuale del tempo di sessione completo: tempo di memorizzazione del buffer/(tempo di riproduzione + tempo di memorizzazione nel buffer). L'aggregazione del rebuffering di tutti gli utenti viene mediata e visualizzata nei dashboard di analisi per evento e mediata per l'intervallo di tempo selezionato nel widget Rebuffering.

Che cos'è un cattivo rebuffering?

Il tre per cento o superiore è considerato un'esperienza scadente.

Intervallo	Codifica a colori	Determinazione
>3%	Rosso	Riteniamo che oltre il 3% sia un'esperienza scadente, che garantisce un'indagine quando viene rappresentata una base di utenti sostanziale.
<3% e >1%	Giallo	Può essere considerato da degradato a preoccupante. Si rileva che in genere l'intervallo giallo è motivo di preoccupazione solo se si trova all'estremità superiore dell'intervallo e solo quando è interessato un gruppo grande o concentrato.
<1%	Verde	È considerata una buona esperienza. In genere, il rebuffering dell'1% nella base di clienti di Microsoft eCDN è ben al di sotto dell'1%.

Come usare il rebuffering per la risoluzione dei problemi

Microsoft eCDN offre metriche di esperienza approfondite, ad esempio il rebuffering, che possono essere usate per convalidare i report di un'esperienza utente scarsa e per determinare l'ambito dei visualizzatori interessati. Può anche essere usato per evidenziare i punti deboli nell'ambiente di rete, in particolare quando si eseguono test di carico con test invisibile all'utente.

Di seguito sono riportati gli scenari in cui il rebuffering può essere una metrica utile.

Verifica dell'età del rilascio

Un primo passaggio comune nella risoluzione dei problemi consiste nell'accertare l'età di un problema. Confrontando la percentuale di buffering dell'evento con gli eventi precedenti, è possibile distinguere un modello distinto in un intervallo di tempo. Le domande da porre possono includere...

• Questo rebuffering è osservato anche negli eventi precedenti o non è persistente?
• Sta rieseguire il buffering di un nuovo evento?
  • In tal caso, è stata apportata una modifica nel mapping della subnet o nella configurazione di rete dall'ultimo evento con un corretto rebuffering. In caso affermativo, cosa?

Esempio di un potenziale problema persistente

In questo screenshot si osserva un problema coerente plausibile a partire da una data specifica con eventi più grandi. A parte le dimensioni dell'evento, è consigliabile osservare altri possibili tratti in comune, ad esempio ISP o gruppo di subnet.

Esempio di singolo evento di rebuffering elevato

In questo screenshot si osserva che il rebuffering elevato per l'evento più grande è un nuovo problema che non era presente negli eventi precedenti. Una buona domanda da porsi qui è se il rebuffering scadente è stato sperimentato attraverso la base dello spettatore o concentrato da qualche parte.

Si noti anche che gli eventi più piccoli successivi sono validi, quindi è giusto presumere che la causa sia relativa a un tratto univoco dell'evento, ad esempio dimensioni, tempistica o altre proprietà.

Escludere l'irregolarità della rete temporanea

Il rebuffering può essere dovuto a incoerenze di rete al di fuori del controllo immediato, ad esempio l'ISP o una rete di distribuzione del contenuto con un'incoerenza momentanea del servizio. Nel dashboard Drilldowns , dopo aver filtrato per un evento specifico e quindi aver selezionato la dimensione Disaggregazione gruppo , viene esaminato il grafico Sequenza temporale di rebuffering per individuare eventuali modelli visivi tra gruppi.

Esempio di rebuffering tra gruppi

In questo screenshot della sequenza temporale di rebuffering per la dimensione Gruppi , osserviamo tre momenti durante questo evento di 90 minuti in cui si è verificato un ribuffering elevato in tutti i gruppi di questa grande organizzazione, all'inizio, a metà e alla fine dell'evento. Questo effetto inter-organizzativo è un indicatore forte dell'origine del problema, che in questo caso era la rete di distribuzione di contenuti dell'organizzazione; una rete CDN, da non confondere con Microsoft eCDN.

Esempio di rebuffering in un singolo gruppo

Analogamente allo screenshot della sequenza temporale citato in precedenza, in questo esempio si osserva anche un momento di rebuffering a livello di organizzazione verso la fine. Inoltre, è anche possibile osservare che uno dei gruppi VPN di questa organizzazione sta riscontrando un ribuffering scadente durante l'evento. Questo potrebbe essere un chiaro indicatore di una mancanza di capacità nel circuito VPN dell'organizzazione. In tal caso, questo gruppo sarebbe un buon test case per analizzare l'impatto del traffico di Teams con split tunneling per ridurre il carico.

Identificazione di una sezione travagliata

Supponendo che non sia evidente una causa generale, procedere nel processo di risoluzione dei problemi per identificare il punto di problemi tagliando sistematicamente i dati nelle varie suddivisioni disponibili nel dashboard Drilldowns di Analytics . Le dimensioni delle scomposizione includono le seguenti.

• Evento
• Gruppo
• Applicazione
• ISP
• Paese
• Città
• Sistema operativo

Limitazioni

Anche con il mapping delle subnet caricato, a volte i punti di rebuffering elevati si trovano in uno dei gruppi predefiniti. Per risolvere i problemi relativi a metriche scarse per questi gruppi, usare le categorie di suddivisione popolate automaticamente, ad esempio le seguenti per filtrare e filtrare i dati.

• Applicazione
• ISP
• Paese
• Città

Riepilogo

La prossima volta che si verifica un ribuffering elevato, cercare modelli e porsi domande come le seguenti.

• Il rebuffering elevato si verifica a livello aziendale o solo in siti specifici?
• Il rebuffering è superiore per sistemi operativi specifici o l'applicazione viene usata per watch l'evento live?
• Il rebuffering si è verificato in un minuto specifico per ogni utente e è andato via qualche tempo dopo?
• Esiste una correlazione tra un momento di rebuffering osservato e un altro evento potenzialmente di impatto sulla rete?

Il rebuffering è un sottoprodotto indesiderato, in genere associato all'inaffidibilità della rete. Con i dashboard di Microsoft eCDN, è possibile ottenere maggiori informazioni sull'origine per risolverlo.