Polling – damit es flutscht

Bei den beiden ZDF-Eventmodulen EM 2016 und Olympia2016 kommt es durch die enge Verknüpfung mit Sportereignissen und TV-Sendungen zu hohen Spitzen bei den Zugriffszahlen – beispielsweise wenn ein Tor fällt, Usain Bolt läuft oder ein Moderator die Website bewirbt. Wir haben uns deshalb für das Polling-Verfahren entschieden, bei dem der Browser in kurzen Abständen von zirka 15 Sekunden neue Daten vom Server abruft. Der Server sendet dann alle aktuellen Daten auf einmal. Ausschlaggebend für die Entscheidung war, dass die Skalierung so über das Content-Delivery-Network Akamai erfolgt, was vergleichsweise einfach einzurichten ist und sehr stabil läuft.

WebSockets, ein Netzwerkprotokoll, das eine bidirektionale Verbindung zwischen einer Webanwendung und einem Webserver herstellt, mögen auf den ersten Blick zwar effizienter erscheinen, weil nur dann Daten übermittelt werden, wenn sich wirklich etwas ändert. Der Nachteil ist jedoch, dass man bei unseren Zugriffszahlen ein deutlich komplexeres Server-Setup benötigt hätte, das damit auch wesentlich anfälliger gewesen wäre – Ausfallsicherheit war bei diesem Projekt jedoch eine entscheidende Anforderung.

Um die Performance weiter zu verbessern, erneuern wir den Cache, noch bevor die Cache-Zeit abgelaufen ist. Auf diese Weise liegen die Daten dann schon im Cache und müssen nicht erst beim nächstne Request zusammengestellt werden Dazu laufen im Hintergrund eine Reihe von asynchronen Workern, also Prozesse außerhalb des Request-/Response-Zyklus, die Daten von den verschiedenen APIs abrufen, diese aufbereiten und in den Cache schreiben.

Die meisten Seiten des Eventmoduls stellen Daten (Fotos, Videos, Liveblog-Einträge et cetera) aus mehreren Quellen dar. Deshalb haben wir einen Feed-Service entwickelt, bei dem die Zusammenstellung der Daten über die URL gesteuert wird, sodass pro Seite nur ein Datenfeed abgerufen werden muss. Diese Flexibilität ist wichtig, weil die Redakteure einer Webseite jederzeit neue Elemente hinzufügen können. Für einen beispielhaften Ablauf nehmen wir an, dass auf einer Seite folgende Elemente dargestellt werden, von denen jedes einen eigenen Feed hat:

• Slideshow im Titel
• Videoliste A
• Videoliste B
• Liveblog Einträge

Im Frontend wird aus den IDs der einzelnen Feeds die URL des Gesamtfeeds für diese Seite zusammengestellt – »/feed-api/liveblog/slideshow/videolist-a/videolist-b/« – und vom Server abgerufen. Auf dem Server zerlegt das Django-Backend die URL wieder, und stellt die Daten den Feed-IDs entsprechend zusammen. Dabei liest das Backend sowohl die einzelnen Datenfeeds als auch den Gesamtfeed immer zuerst aus dem Cache.

Stephan Jäkel, Senior Backend Developer, und Norman Rusch, Senior Frontend Developer bei der Agentur für Digital Experience Moccu in Berlin, haben ein tägliches Mantra: »Übrigens, die API der Datenquelle hat sich schon wieder geändert – da muss ich noch mal ran.«
www.moccu.com

Weitere Artikel zu diesem Thema:

Live is Life beim ZDF

Interface Design mit Sketch