Webtest-Leistungen der ARGE Rundfunk-Betriebstechnik (RBT)

Transkript

1 eine Arbeitsgemeinschaft von ARD und ZDF Webtest-Leistungen der ARGE Rundfunk-Betriebstechnik (RBT) Stand 02/2013 Die RBT kann die Performance und Zuverlässigkeit von Internet-Auftritten, CMS-Anwendungen und Web-Streaming untersuchen, um die Zufriedenheit von Nutzern und die Rentabilität von Investitionen sicherzustellen. Mit der zunehmenden Anzahl und Bedeutung webbasierender Angebote und Anwendungen im Rundfunk baut die RBT ihre Kapazität und Kompetenz für Webtests weiter aus. Die nachfolgenden Seiten skizzieren den aktuellen Stand der hierzu, z.b. für Planung, Betrieb oder Entwickler, abrufbaren Leistungen. CDN Internet-Auftritt CMS-Anwendung Web-Streaming s. Kapitel 2, Seite 3 s. Kapitel 3, Seite 5 s. Kapitel 4, Seite 6 Grundlagen und Ansprechpartner für RBT-Webtests s. Kapitel 1, Seite Nürnberg - Wallensteinstraße 119 Telefon Fax Geschäftsführer: Dipl.-Ing. (FH) Alfred Preissner Mitglieder der ARGE: Bayerischer Rundfunk Hessischer Rundfunk Mitteldeutscher Rundfunk Radio Bremen - Rundfunk Berlin Brandenburg Saarländischer Rundfunk Südwestrundfunk Westdeutscher Rundfunk Zweites Deutsches Fernsehen

2 1 Grundlagen der RBT-Webtests Protokolle HTTP(S), SOAP, RTSP, Jabber (XMPP) und RTMP 1 einsetzbar für Tests von Web-Server Anwendungs-Server Datenbank Streaming-Server Reverse Proxy Content Management System (CMS) Content Delivery Network (CDN) Monitoring aller System-Indikatoren gängiger Webserver, Betriebsysteme, Anwendungsserver, Datenbanken und Netzwerkkomponenten korreliert zu Lastverlauf und Antwortzeiten, mit automatischem Alarm beim Überschreiten kritischer Schwellwerte, ohne FW- Öffnung und SW-Installation auf Ihren Systemen beliebig viele weltweite Cloud-Lastrechner zusätzlich zu 4 eigenen Lastgeneratoren mit je 100 Mbit/s Internet-Anbindung am Provider-Backbone verfügbare Personalstärke mit spezifischer Webtest-Kompetenz: 2 Schulung auf Systeme und Testverfahren sowie Zertifizierung auf das eingesetzte Weblasttool Ausrichtung nach relevanten Standards wie IEEE 829 und DIN / ISO Aufarbeitung und Dokumentation der Ergebnisse in flexibler Form langjährige Webtest-Erfahrung mit unterschiedlichen Lasttools bei Internet-Auftritten und Web-Anwendungen von BR, DR, IVZ, SWR, MDR, WDR und ZDF Ihre Ansprechpartner für RBT-Webtests: Claus-Georg Pleyer Christian Pohle Tel.: Tel.: claus-georg.pleyer@rbt-nbg.de christian.pohle@rbt-nbg.de RBT-Sachgebiet IT, Leitung: Jürgen Wehner, Tel.: -190, juergen.wehner@rbt-nbg.de Ihre Fragen beantworten wir jederzeit gerne. Darüber hinaus freuen wir uns über Anregungen, durch die wir unser Leistungsangebot verbessern und weiterentwickeln können. 1 HTTP(S) = Hypertext Transfer Protocol (Secure); SOAP = Simple Object Access Protocol; RTSP = Realtime Streaming Protocol; XMPP = Extensible Messaging a. Presence Protocol; RTMP = Realtime Messaging Protocol Seite 2 von 8

3 2 Internet-Auftritt 2.1 Last- und Streßtests mit korreliertem Monitoring Ein Streßtest Ihres Internet-Auftritts beantwortet folgende Fragen: Wie viele Nutzer kann Ihr Auftritt zufriedenstellend bedienen? Welche Effekte zeigen plötzliche Lastspitzen bei Großereignissen? Wurde an alle Caching- und Content-Optimierungen gedacht? Wann laufen System-Indikatoren in kritische Bereiche? Wo lohnen sich welche Hardware-Investitionen? Statt nur Benchmark-Charakter tragen die RBT-Tests die Merkmale realer Lasten: bis zu gleichzeitige Nutzer simulierbar, z.b. für ereignisabhängige Spitzenlasten beliebiges Surfverhalten mit variablen Klickpfaden und dynamischen Parametern unbegrenzte Skalierung und Verteilung der Zugriffe durch Cloud-Lastgeneratoren Simulation unterschiedlicher Nutzer-Bandbreiten und Endgeräte Fehleranalyse und automatische Verifikation der Antworten auf erwartete Inhalte Dokumentation von Seitenladezeiten, Engpässen, Last- und Fehlergrenzen u.v.m. Legende: Steuerung Last Monitoring Auswertung Abbildung 1: Verteilte Belastung und korrelierte Überwachung eines Web-Systems durch die RBT Seite 3 von 8

4 2.2 Last- und Streß-Vergleichstests Ein Web-Vergleichstest beantwortet folgende Fragen: Wie beeinflussen Content-Aktualisierungen die Performance Ihres Systems? Was bewirken Ihre Optimierungen und Konsolidierungen in meßbarer Weise? Wie zahlen sich Ihre Investitionen in neue oder zusätzliche Hard- und Software aus? 2010 Performance-Verbesserung Nutzer 716 Nutzer Abbildung 2: Seiten-Antwortzeit [s] und Fehlerrate über der Nutzeranzahl eines kleinen Portals in 2010 und Automatische Webseiten-Überwachung Seit mehreren Jahren überwacht die RBT periodisch Webseiten auf bestimmte Eigenschaften und stellt das Ergebnis automatisch per -Verteiler zu. Umfang, Tiefe und Periodizität der automatischen Webseiten-Überwachung werden individuell an Ihre Anforderungen angepaßt. Dies beantwortet z.b. folgende Fragen: Sind alle Objekte richtig in einer Seite eingebunden? Überschreiten Seiten-Objekte (z.b. Bilder) eine sinnvolle Größe? Liegt das Datenvolumen der gesamten Seite (inklusive aller beinhalteten Elemente) unter einem vorgegebenen Schwellwert? 2.4 Funktions- und Kompatibilitätstests Seit 2013 testet die RBT für die ARD die korrekte Darstellung und Funktionsweise von Web- Angeboten für mobile Endgeräte und dokumentiert dies in einem Fehlermanagementsystem. Seite 4 von 8

5 3 Web-Anwendung und Web-Services Getestete und testbare Last- und Streßtest-Untersuchungsobjekte: Mobile Apps, Chats, Foren, Communities, Umfragen, Online-Spiele, etc. Redaktionssysteme, wie z.b. das Video Production Management System (VPMS) Planungssysteme, wie z.b. OpenMedia Produktionsplanungs- und Steuerungs-Systeme (PPS) Wichtige Fragen beim Streßtest einer Web-Anwendung: Ab wann müssen Anwender mit einer trägen Reaktionszeit rechnen? Liefern Hard- und Software die versprochene Performance? Bleiben bei Überlast Ihr System stabil und die Daten konsistent? Realtypische Interaktionen durch dynamisch parametrisierte Last Last- Abbildung 3: PPS-/VPMS/OpenMedia-Testobjekte mit dynamischen Requests von simulierten Anwendern Die Tests beinhalten u.a. folgende Verfahren: automatisiertes Anlegen und Löschen von Datensätzen realistische Manipulation der Datensätze unter verschiedenen Logins Dynamisierung von XML 2 -Content von SOAP 3 -Requests korreliertes Monitoring beteiligter Software-Komponenten zur Engpaß-Eingrenzung 2 XML = Extensible Markup Language 3 SOAP = Simple Object Access Protocol Seite 5 von 8

6 4 Web-Streaming 4.1 Verfügbarkeits-Tests Die folgenden drei Fälle zeigen die mit zwei Testagenten möglichen Auswertungen von nichtverfügbaren oder fehlerhaften Streams ( ), die von zwei CDN-Providern ausgeliefert werden - und die dadurch mögliche Eingrenzung der Fehlerquelle ( ): Fall A: gleicher Stream über zwei DSL-Provider fehlerhaft CDN-Provider-Problem 4 1 DSL-Provider 1 CDN 1 CDN 2 DSL-Provider 2 2 Fall B: ein Stream über einen DSL-Provider fehlerhaft CDN-DSL-Peering/Transit-Problem 1 DSL-Provider 1 CDN 1 CDN 2 DSL-Provider 2 2 Fall C: beide Streams über einen DSL-Provider fehlerhaft regionales DSL-Provider-Problem 3.2 Qualitäts-Tests DSL- Provider 1 CDN 1 CDN 2 DSL-Provider DSL = Digital Subscriber Line; CDN = Content Delivery Network; = Stream verfügbar/fehlerfrei Seite 6 von 8

7 4.2 Qualitäts-Tests Das von der RBT eingesetzte Testsystem NeoLoad kann seit der neuen Version 4 von 2012 Aussagen über die Qualität des empfangenen Audio/Video-Streams aus Sicht des Endnutzers machen, z.b. zu Startverzögerung, Pufferung und Unterbrechungszeiten. Abbildung 4: Pufferfüllstand (grün), Startverzögerung (gelb) u. Unterbrechung (rot) eines Streams in Sekunden Mit weiteren Tools können außerdem die Statistiken des MS Windows Media Player genutzt werden, wie z.b. ReceptionQuality, MinimumBitRate, MinimumActualFrameRate, PacketsLost. 4.3 Live-Stream-Monitoring Neben der Evaluierung anderer Tools hat die RBT in 2012 einen Streaming-Monitoring-Pilottest für einen HTTP-Hörfunkstream mit der Software NeoLoad betrieben. Dabei zeigt eine zugangsgeschützte Webseite die Ladedauer, den Pufferfüllstand und die Unterbrechungszeit des Streams und stellt vergangene Testzeiträume zum Abruf bereit. Hier lassen sich weitere Streams und Monitoring-Standorte sowie Statistiken über die Ausfallzeiten der Vergangenheit nach Ihren Anforderungen integrieren und die Konfiguration flexibel anpassen: - beliebige Zusammenfassung oder Aufteilung von Streams und Standorten in Graphen - Stream-Neuaufruf nach beliebigen Perioden - beliebige Testdauer in einem Graphen (z.b.: 1h, 1d) - statistische Auswertungen über die o.g. Testdauer oder längere Zeiträume - Simulation von beliebigen Browsern - Simulation von beliebigen Endgeräten - Simulation von beliebigen Anschluß-Bandbreiten und Netzwerkfehlern Seite 7 von 8

8 Abbildung 5: Pilot-RBT-Webseite zum Streaming-Monitoring 4.4 Geolocation/Geoblocking-Tests Die RBT kann die Einhaltung des erlaubten Verbreitungsgebietes für Streams und damit die rechtlich relevante Beachtung der Geolocation/Geoblocking -Vorgaben für den Content überprüfen. Hierzu validieren weltweit verteilte Testagenten die Streams auf bestimmte Antworten. Fehlt der erwartete Inhalt, ist der Stream wie beabsichtigt nicht abrufbar. Seite 8 von 8