eine Arbeitsgemeinschaft von ARD und ZDF Webtest-Leistungen der ARGE Rundfunk-Betriebstechnik (RBT) Stand 2012 Mit der zunehmenden Anzahl und Bedeutung web-basierender Angebote und Anwendungen im Rundfunk hat die RBT ihre Kapazität und Kompetenz für Webtests weiter ausgebaut. Sie kann die Performance und Zuverlässigkeit von Internet-Auftritten, Web-Anwendungen und Web-Streaming-Angeboten untersuchen, um die Zufriedenheit von Nutzern und die Rentabilität von Investitionen sicherzustellen. Die nachfolgenden Seiten skizzieren den aktuellen Stand der, z.b. für Planung, Betrieb oder Entwickler, hierzu abrufbaren Leistungen. CDN Internet-Auftritt Web-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 2 90431 Nürnberg - Wallensteinstraße 119 Telefon 0911-6573-0 - Fax 0911-6573-111 www.rbt-nbg.de 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
1 Grundlagen der RBT-Webtests Protokolle HTTP(S), SOAP, RTSP, Jabber (XMPP) und RTMP 1 einsetzbar für Tests von Content Management System (CMS) Web-Server Anwendungs-Server Reverse Proxy Streaming-Server Datenbank Content Delivery Network (CDN) Monitoring aller System-Indikatoren von Windows,.NET, IIS, Linux, Apache und Tomcat korreliert zu Lastverlauf und Antwortzeiten, mit automatischem Alarm beim Überschreiten kritischer Schwellwerte, ohne SW-Installation auf Ihren Systemen und erweiterbar um andere beteiligte Systeme 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 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.: 0911-6573-225 Tel.: 0911-6573-194 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, mit denen 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 7
2 Lasttest Internet-Auftritt 2.1 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? Abbildung 1: Verteilte Belastung und korrelierte Überwachung eines Web-Systems durch die RBT Statt nur Benchmark-Charakter tragen die RBT-Tests die Merkmale realer Lasten: bis zu 5.000 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. Seite 3 von 7
2.2 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 2012 104 Nutzer 716 Nutzer Abbildung 2: Seiten-Antwortzeit [s] und Fehlerrate über der Nutzeranzahl eines kleinen Portals in 2010 und 2012 Seite 4 von 7
3 Lasttest Web-Anwendung und Web-Services Beispiele: Mobile Apps, Chats, Foren, Communities, Umfragen, Online-Spiele, etc. Redaktionssysteme wie z.b. das Video Production Management System (VPMS) Produktionsplanungs- und Steuerungs-Systeme (PPS) Wichtige Fragen beim Streßtest einer Web-Anwendung: Liefern Hard- und Software die Ihnen versprochene Performance? Ab wann müssen Ihre Anwender mit einer trägen Reaktionszeit rechnen? Bleibt Ihr System bei Überlast stabil und bleiben die Daten konsistent? Realtypische Interaktionen durch dynamisch parametrisierte Last Last- Generator Abbildung 3: PPS-/VPMS-Testobjekte mit dynamischen Requests von hunderten simulierten Anwendern Bisherige RBT-Tests umfaßten z.b. folgende Verfahren: automatisiertes Anlegen und Löschen von Datensätzen eines PPS realistische Manipulation der PPS-Datensätze unter verschiedenen Logins Dynamisierung von XML 2 -Content der SOAP 3 -Requests zum VPMS korreliertes Monitoring beteiligter Software-Komponenten zur Engpaß-Eingrenzung 2 XML = Extensible Markup Language 3 SOAP = Simple Object Access Protocol Seite 5 von 7
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 Rückführung auf einen lokalen Engpaß oder Ausfall ( ): 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 2 1 2 4 DSL = Digital Subscriber Line; CDN = Content Delivery Network; = Stream verfügbar/fehlerfrei Seite 6 von 7
4.2 Qualitäts-Tests Das von der RBT eingesetzte Testsystem NeoLoad kann in der neuen Version 4.0 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: Wiedergabe-Unterbrechungen bei einem Stream über DSL (keine; grün) und ISDN (bis zu 10s; rot) 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 Geolocation/Geoblocking-Tests Die RBT kann die Einhaltung des erlaubten Verbreitungsgebietes für Streams überprüfen. Hierzu werden Testagenten im Nicht-Verbreitungsgebiet eingesetzt, die den Stream auf bestimmte Antworten validieren. Fehlt der entsprechende Inhalt, kann er, wie beabsichtigt, auch nicht abgerufen werden. Dies dient als erfolgreicher Nachweis der Einhaltung der Geolocation/Geoblocking -Vorgaben für den Content. Abbildung 5: Cloud-Lastrechner-Beispiele des Web-Testtools NeoLoad Seite 7 von 7