Tipps & Tricks zum RS RainRadar Forecast
Ich habe im RS RainRadar Forecast eine spezielle Variable, in der die Anzahl der Downloadversuche für das neue Radar-GIF von wetteronline.de abgelegt wird. Das ist u.A. Nötig, um die Synchronisation der herunter geladenen GIF’s mit dem Viertelstunden-Intervall zu unterstützen, es soll aber auch eine Fehlersuche unterstützen, wenn die GIF’s nicht synchron zum Viertelstundenintervall angezeigt werden.
Diese Download-Versuche werden nicht nur stumpf in die Variable geschrieben und im WFE angezeigt, sie werden auch geloggt. So kann man die Vergangenheit analysieren und unter Anderen herausfinden, ob und wann Download-Versuche nicht erfolgreich waren. Man kann auch heraus finden, nach wie vielen Versuchen durchschnittlich ein erfolgreicher Download erfolgt.
Und genau das soll heute das Thema des Beitrags sein.
Grundlagen-Wissen
Wie genau funktioniert der GIF-Download?
Nun, die Radar-Gif-Bilder (für den Forecast) werden von Wetteronline im Viertelstunden-Intervall online gestellt. Und im Viertelstunden-Intervall sollen diese vom RS RainRadar Forecast abgeholt und analysiert werden. Und dies so früh wie möglich (innerhalb eines Viertelstunden-Intervalls), um dem System/Anwender genügend Vorwarnzeit zu geben. Daraus resultiert ein Bestreben, den Download möglichst früh innerhalb eines jeden Intervalls zu starten.
Nun hat sich aber herausgestellt (und in den letzten Monaten gabs dazu reichlich Beiträge im IPS-Forum), dass der Bereitstellungszeitpunkt nicht fix ist, sondern dynamisch. Heißt konkret: mal steht ein neues GIF 6 Minuten nach Beginn der Viertelstunden bereit, mal aber auch erst nach 14 Minuten (Extremfall, aber schon öfter erlebt). Dann hat man quasi NULL Vorwarnzeit.
Im RS RainRadar Forecast ist der Download-Start daher fix auf ca 5 Minuten nach Beginn eines Viertelstunden-Intervalls festgelegt. Ab dann beginnt das Projekt, nach neuen GIF’s suchen, in dem es alle 15 Sekunden das Radar-GIF von Wetteronline abholt und mit dem GIF aus dem letzten Zyklus vergleicht. Liegt ein neues GIF vor, wird der Download-Zyklus beendet, das GIF wird an die Datenanalyse übergeben (und der Wert in der Variable „DL-Versuche“ auf 0 gesetzt).
Das „Problem“
Das oben beschriebene Vorgehen führt dazu, dass ein Download mal nach 2 Versuchen, manchmal aber erst nach 30 Versuchen erfolgreich war (erfolgreich bedeutet in diesem Kontext: ein neues GIF liegt vor). Das erzeugt Traffic. Nicht viel: ein GIF ist ca 200kB groß.
Rechnet man das aber auf einen Tag hoch, dann kommen ohne Probleme 500MB zusammen. Jeden Tag. Und das nur, um möglichst frühzeitig zu einem aktuellen Bild zu kommen. Würde der Download gleich beim ersten Versuch zu einem neuen GIF führen, käme man am Tag auf nicht einmal 24MB. Das wäre ein zwanzigstel des heute erzeugten, täglichen Traffics. Nachdem neuerdings Download-Volumen durch die Internet-Provider thematisiert wird -allen voran die pinkfarbene DrosselCom, könnte das ein Thema werden.
RS RainRadar Forecast: Ausgangslage
Die Analyse
Die spannende Frage ist ja: sind denn diese vielen „Download-Fehlversuche“ wirklich nötig?
Antwort: jein! Ganz klar: wie immer muss man Kompromisse machen und sich (in diesem Fall) entscheiden: will ich zu 100% GIF’s mit maximaler Vorwarnzeit – oder reichen mir auch 98%?
Im Auslieferungszustand ist das Projekt so eingestellt, dass man möglichst dicht an die 100% Trefferquote kommt. Also möglichst kein GIF, welches schon beim ersten DL-Versuch als neu identifiziert ist und damit zu spät abgeholt wurde. Also startet man den DL-Zyklus möglichst kurz nach Beginn der Viertelstunde.
RS RainRadar Forecast: Ausgangslage Tagesbasis
Will ich das optimieren, muss ich als Anwender selbst eine Entscheidung treffen. Ich selbst kann durchaus mit 98% leben (musste mich dazu aber überreden). Die Frage ist: was kann ich tun?
Zunächst habe ich mir die geloggten Daten der „DL-Versuche“ Variable angeschaut. Da habe ich festgestellt, dass die Anzahl der DL-Versuche pro Intervall bei ca 23 liegt. Und das verhältnismäßig konstant.
Es gab mal ein paar Ausreißer nach oben, es gibt recht oft Ausreißer nach unten – aber nicht dramatisch nach unten. Ab und zu kommt es vor, dass ein GIF schon beim ersten DL-Versuch als neues GIF identifiziert wird. In diesem Fall ist der DL-Zyklus eindeutig zu spät gestartet. Wie viel zu spät weiß man aber nicht.
Schematische Darstellung der Optimierung
Also ergab sich schnell die Überlegung, den Start eines DL-Zyklus vorsichtig auf einen späteren Zeitpunkt zu verschieben, ohne nennenswerte Einbußen in der Vorwarnzeit in Kauf nehmen zu müssen.
Im Bild Rechts (schematische Darstellung) wäre die Auswirkung folgende: die X-Achse (=Nullwert) würde um ca 12 Punkte angehoben (grüne Linie). Das würde zu weiteren 2 „Fehler“ (also zu spät erfolgten Downloads) an diesem Tag führen (gelb markiert).
Die Lösung
DL-Versuche: Vergleich vorher-nachher
Kann man mit 98% leben, dann gibt es ein erstaunlich einfaches, aber sehr wirksames Mittel. Die Überlegung war, die Anzahl der Fehlversuche zu reduzieren. Das kann man erreichen, in dem man den Startzeitpunkt eines DL-Zyklus nach hinten verschiebt. Also statt diesen 5 Minuten nach Beginn der Viertelstunde zu starten – vielleicht 6, 7 oder 10 Minuten?
Pro Minute werden 4 DL-Versuche ausgelöst. Bei 2 Minuten Verschiebung wären das 8 eingesparte DL-Versuche pro Viertelstunde, pro Tag wären das 768 DL-Versuche weniger. Hola!
Die Frage hierbei ist aber: um welchen Preis? Oder anders gefragt: wie häufig ist der DL dann zu spät erfolgt? => weil genau darauf wird der Kompromiss hinauslaufen.
DL-Zyklen: Tages-Vergleich vorher-nachher
Ich habe mich vorsichtig ran getastet und den DL-Zyklus Start um 3 Minuten nach hinten verschoben. Statt bisher 5 Minuten nach Beginn der Viertelstunde startet der DL-Zyklus nun 8 Minuten nach Beginn der Viertelstunde. Diese Umstellung habe ich am 04.10.2013 vorgenommen, was man auch sehr gut im 1. Bild sehen kann.
Das Ergebnis
Inzwischen sind 3 Wochen vergangen und das Ergebnis hat mich sehr positiv überrascht. Nicht nur die Anzahl der DL-Versuche ist gesunken (von ca 22/Intervall auf ca 13/Intervall) – und damit logischerweise auch der Traffic (von knapp 500MB/Tag auf knapp 300MB/Tag), auch die Erfolgsquote wesentlich weniger abgesunken als befürchtet. Mit Erfolgsquote meine ich DL-Zyklen, die vor der Bereitstellung eines neuen GIF’s durch wetteronline.de gestartet sind -> also mindesten einen DL-Fehlversuch hatten und damit die maximale Vorwarnzeit gewährleisten.
Im nebenstehenden Bild habe ich mal die zu „spät gestarteten“ DL-Zyklen markiert (grüne Pfeile). Und zwar einmal für den 02.10 (also vor der Änderung der Startzeit des DL-Zyklus) und einmal für den 24.10. (nach Verschiebung des DL-Zyklus um 3 Minuten). Am 02.10. gab’s einen DL, der zu spät startete, am 24.10. (nach der Umstellung) waren es 2. In der Regel hatte ich in den vergangenen Wochen zwischen 2 und 6 solcher Events pro Tag. Und ich kann damit hervorragend leben.
Zusammenfassung
WEB Traffic vorher-nachher
Der obige Text ist reichlich blumig und lang, daher hier die Zusammenfassung für Diagonal-Leser:
Verschiebt man den Start des Download-Zyklus des RS RainRadar Forecast um 3 Minuten (nach hinten), so reduziert sich der Web-Traffic von ca 500MB/täglich auf ca 300MB/täglich bei fast gleichbleibender Trefferquote/max. Vorwarnzeit.
Die Einstellung des DL-Zyklus-Starts im RS RainRadar Forecast zeigt nebenstehendes Bild.
Änderung Scripttiming
Eigentlich ganz einfach, oder?
Was ich hier aber -quasi nebenbei – mit aufzeigen will, ist das Potenzial der Analyse von geloggten Daten sowie die anschließende Erfolgsüberwachung durch Logging von Messdaten. Vielleicht hat’s ja bei dem Ein- oder Anderen zu aha-Effekten geführt ;-)
Nachtrag
Vielleicht noch ein Wort zum Daten-Logging im RS RainRadar Forecast:
Da nach der Installation bei fast allen Variablen im RS RainRadar Forecast das Datenlogging aktiviert ist, kommen hier mitunter beachtliche Datenmengen zusammen. Der Treiber in diesem Kontext ist die Variable „DL-Versuche“, die es am Tag ohne Weiteres auf 1900 Datensätze bringt. Natürlich wird das nach oben beschriebenem Vorgehen weniger. Aber das sind Daten, die man langfristig nicht braucht (außer zur Projektanalyse).
Dem kann man auf 2 Arten begegnen:
- man schaltet das Logging ab (Variablen-Eigenschaften)
- man bedient sich des RS DB Analyzers, der das Datenvolumen vollautomatisch begrenzen kann.
