Risoluzione dei problemi di bassa efficienza del peering

In questo articolo vengono elencate le cause comuni per la bassa efficienza del peering e come risolverle.

Avviso

Se si esegue un evento live stream, Yammer o Viva Engage, è possibile che si verifichi una riduzione dell'efficienza del peering. Il problema è attualmente in fase di analisi e questo messaggio verrà rimosso una volta risolto. Grazie per la comprensione.

Piccoli eventi live

In genere più popolare è l'evento, maggiore è il livello di prestazioni di offload. Tenere presente che almeno un visualizzatore in un gruppo di peering dovrà scaricare i dati dall'origine originale. Pertanto, se sono presenti solo 2 visualizzatori in un gruppo, l'efficienza/offload massimo del peering è 50%, 3 visualizzatori=> 67%, 4 => 75% e così via.

Escludendo i casi perimetrali, Microsoft eCDN SDK crea fino a 30 connessioni di peering. Solo i visualizzatori che guardano lo stesso contenuto di risoluzione eseguono il peering tra loro. Aumentando il numero di visualizzatori in un gruppo, i pool di peer disponibili vengono espansi, migliorando in modo efficace il potenziale di efficienza del peering.

Accesso TLE client non ottimale

Per l'esperienza di Teams Live Event più ottimizzata, tutti i visualizzatori devono partecipare tramite l'applicazione Desktop di Teams. Con il client Teams, Microsoft eCDN ottiene automaticamente gli INDIRIZZI IP locali degli utenti finali e li associa in modo efficace tra loro.

Se gli spettatori si uniscono tramite il browser, assicurarsi che concedano l'accesso al microfono o alla fotocamera al sito Web di Teams o che il mascheramento IP mDNS sia disabilitato. In questo modo, verrà esposto l'indirizzo IP locale necessario per il peering. Per altre informazioni, vedere la documentazione relativa alla disabilitazione della maschera IP mDNS .

Mancanza di mapping delle subnet

Con Microsoft eCDN, gli amministratori possono incorporare il proprio mapping di subnet per creare gruppi/restrizioni di peering in base all'IP locale. Vantaggi:

• Solo i visualizzatori che si trovano nella stessa rete eseguono il peering tra loro

• È possibile impedire il peering tra siti

• L'analisi arricchita mostra prestazioni e peering basati sul sito

• Le subnet VPN (e altre subnet per le quali gli amministratori vogliono disabilitare il peering) possono essere escluse in modo esplicito

Le subnet possono essere caricate direttamente nella pagina Mapping subnet del portale Microsoft eCDN. Il formato di mapping della subnet richiesto è un file CSV con la struttura seguente.

Per indicazioni e opzioni aggiuntive su come preparare il csv per il caricamento, vedere la documentazione sul mapping delle subnet .

Senza il mapping delle subnet, tutti i client (che espongono correttamente l'INDIRIZZO IP locale all'SDK eCDN) saranno liberi di eseguire il peering tra loro. Questo è ideale per massimizzare il potenziale numero di peer, ma può consentire la creazione di connessioni peering indesiderate, ad esempio tramite canali VPN o siti distanti, con conseguente riduzione delle prestazioni.

Raggruppamento di subnet suddivise in hyper

Simile per natura al caso di piccoli eventi live sopra. Se le subnet sono suddivise in modo troppo aggressivo, il potenziale di offload corrispondente verrà ridotto proporzionalmente.

Latenza elevata tra due client

Eseguire un test di latenza. Per un'esperienza ottimale, la latenza tra due client deve essere inferiore a 30 ms. Per proteggere l'esperienza utente, i client non utilizzeranno connessioni di peering scarse con latenza elevata. Una potenziale causa di latenza elevata potrebbe essere dovuta a un numero eccessivo di persone connesse a un singolo dispositivo di rete, ad esempio un punto di accesso o switch.

Utilizzo di una VPN (rilevante solo per i test)

Ciò è rilevante solo per la persona che amministra un test da casa e usa altri dispositivi personali. Verificare che la VPN sia disabilitata nei dispositivi di test.

Se si è in ufficio, non è consigliabile accedere al contenuto video tramite una VPN.