Problembehandlung bei geringer Peeringeffizienz

In diesem Artikel werden häufige Ursachen für eine niedrige Peeringeffizienz und deren Behebung aufgeführt.

Kleines Liveereignis

Im Allgemeinen gilt: Je beliebter das Ereignis ist, desto stärker ist die Auslagerungsleistung. Beachten Sie, dass mindestens ein Viewer in einer Peeringgruppe die Daten aus der ursprünglichen Quelle herunterladen muss. Wenn also nur zwei Zuschauer in einer Gruppe vorhanden sind, beträgt die maximale Peeringeffizienz/-auslagerung 50 %, 3 Viewer => 67 %, 4 => 75 % usw.

Ohne Edgefälle erstellt das Microsoft eCDN SDK bis zu 30 Peeringverbindungen. Nur Zuschauer, die die gleiche Auflösung ansehen, peeren miteinander. Durch die Erhöhung der Anzahl von Zuschauern in einer Gruppe werden die Pools der verfügbaren Peers erweitert, wodurch das Peeringeffizienzpotenzial effektiv verbessert wird.

Suboptimaler Clientzugriff

Für die optimiertste Liveereignis- und Rathauserfahrung von Teams sollten alle Zuschauer über die Teams Desktop-Anwendung teilnehmen. Mit dem Teams-Client erhält Microsoft eCDN automatisch die lokalen IP-Adressen der Endbenutzer und stellt sie effektiv miteinander in Verbindung.

Wenn Zuschauer über den Browser beitreten, stellen Sie sicher, dass sie Mikrofon- oder Kamerazugriff auf die Teams-Website gewähren oder die mDNS-IP-Maskierung deaktiviert haben. Dadurch wird die lokale IP-Adresse verfügbar gemacht, die für das Peering erforderlich ist. Weitere Informationen finden Sie in der Dokumentation zum Deaktivieren der mDNS-IP-Maskierung .

Fehlende Subnetzzuordnung

Mit Microsoft eCDN können Administratoren ihre eigene Subnetzzuordnung integrieren, um Peeringgruppen/Einschränkungen basierend auf der lokalen IP-Adresse zu erstellen. Die Vorteile sind:

• Nur Viewer, die sich im selben Netzwerkpeer untereinander befinden

• Standortübergreifendes Peering kann verhindert werden

• Angereicherte Analysen zeigen sitebasiertes Peering und Leistung an

• VPN-Subnetze (und andere Subnetze, für die Administratoren das Peering deaktivieren möchten) können explizit ausgeschlossen werden.

Subnetze können direkt auf die Seite Subnetzzuordnung des Microsoft eCDN-Portals hochgeladen werden. Das erforderliche Subnetzzuordnungsformat ist eine CSV-Datei mit der folgenden Struktur.

In der Dokumentation zur Subnetzzuordnung finden Sie Anleitungen und weitere Optionen zum Vorbereiten Ihrer CSV-Datei für den Upload.

Ohne Subnetzzuordnung können alle Clients (die ihre lokale IP-Adresse erfolgreich für das eCDN SDK verfügbar machen) peering miteinander herstellen. Dieses Szenario eignet sich hervorragend für die Maximierung der potenziellen Peeranzahl, kann jedoch unerwünschte Peeringverbindungen ermöglichen, z. B. über VPN-Kanäle oder über entfernte Standorte hinweg, was zu einer schlechteren Leistung führt.

Hyper-unterteilte Subnetzgruppierung

Ähnlich wie der oben erwähnte Fall eines kleinen Liveereignisses . Wenn Subnetze zu aggressiv unterteilt werden, wird das entsprechende Abladungspotenzial proportional reduziert.

Hohe Latenz zwischen zwei Clients

Führen Sie einen Latenztest durch. Für eine optimale Erfahrung sollte die Latenz zwischen zwei Clients weniger als 30 ms betragen. Um die Benutzererfahrung zu schützen, verwenden Clients keine schlechten Peeringverbindungen mit hoher Latenz. Eine mögliche Ursache für eine hohe Latenz könnte darin liegen, dass zu viele Personen mit einem einzelnen Netzwerkgerät verbunden sind, z. B. mit einem Zugriffspunkt oder Switch.

Verwendung eines VPN (nur für Tests relevant)

Dieses Szenario ist nur für die Person relevant, die einen Test von zu Hause aus verwaltet und andere persönliche Geräte verwendet. Stellen Sie sicher, dass VPN auf Testgeräten deaktiviert ist.

Wenn Sie im Büro sind, wird nicht empfohlen, über ein VPN auf die Videoinhalte zuzugreifen.

Falsche lokale IP-Identifikation

Drücken Sie ALT+UMSCHALT+P in einem von Microsoft eCDN unterstützten Videofenster, um die Statistiküberlagerung zu öffnen. Es kann eine andere IP-Adresse als die erwartete lokale IP-Adresse beobachtet werden. In diesem Szenario wird der Viewer der falschen Subnetzgruppe zugewiesen, möglicherweise der Gruppe Nicht gruppiert (kein Peering). Wenden Sie sich an Ihren Microsoft Customer Success Account Manager (CSAM), um eine Lösung zu erhalten.