Exakt passende Differenzlisten
-
Hallo zusammen,
in verschiedenen Threads geht es um die dringend erforderliche Reduzierung des Traffics für die Filmlisten. Dazu gibt es schon jetzt die Differenzlisten. Soweit ich das verstanden habe, bezieht sich die Differenzliste auf die erste vollständige Liste des aktuellen Tages (sog. Org-Liste).
Mein Vorschlag ist, mehrere Differenzlisten zu erstellen und zwar jeweils eine für jede der in letzten Tagen angebotenen aktuellen Filmlisten, z.B. 48 Differenzlisten für jede der vergangen 48 aktuellen Filmlisten.
Ja, das kostet auf dem Server etwas Speicherplatz und etwas Rechenzeit, spart aber erheblich Traffic, weil der Mediathekview-Client die exakt zur lokal vorhandenen Liste passende Differenzliste verwenden kann und das daraus produzierte Ergebnis aus Benutzerperspektive in jeder(!) Hinsicht genauso gut ist, wie aktuelle Liste.
Jede aktuelle Filmliste enthält im ersten Eintrag ein Erstellungsdatum, das in den Namen der Differenzliste einfließen würde, z.B. Filmliste-diff-2018-09-27-08-19-28.xz. Kommt die neue aktuelle Liste werden auch alle vorhandenen Differenzlisten aktualisiert/überschrieben. Nur die älteste nicht, die würde gelöscht werden, dafür kommt eine neue mit dem Datum der zuvor aktuellen Liste hinzu. Die Anzahl der Differenzlisten bleibt also immer gleich.
Der Client könnte anhand des Erstelldatum der lokalen Liste die exakt(!) passende Differenz laden. Wenn die lokale Liste zu alt ist, lädt er eben die vollständige aktuelle Liste. Ob die passende Differenzliste oder die vollständige Liste geladen wurde, ist also für den Benutzer (bis auf die geringere Ladezeit) vollkommen egal (transparent).
Den Haupttraffic dürften die Benutzer verursachen, die die Liste regelmäßig, z.B. täglich oder alle zwei Tage laden. Und bei denen ist gleichzeitig die Größenunterschied zwischen aktueller Liste und Differenzliste am stärksten.
Natürlich kann man den Zeitraum, für die man Differenzlisten anbietet, nach Bedarf bzw. größtem Nutzen festlegen, also z.B. auch für 72 oder noch mehr Stunden zurück. Doch weniger als 36-48 Stunden sollten es wohl nicht sein.
Das Geschriebene soll ausdrücklich als Ausgangsbasis für weitere Überlegungen dienen. Denn natürlich müsste man bei einer Umsetzung noch das eine oder andere Detail berücksichtigen. Trotzdem denke ich, dass der Aufwand für die Umsetzung der Idee überschaubar und vor allem relativ simpel ist. Mit anderen Worten: Vielen Dateien, aber wenig Komplexität.
Ich schätze, dass der Traffic sich durch die Maßnahme mindestens halbiert und im Gutfall auf ein Zehntel sinkt (Faktor 10). Und das ohne jegliche Nachteile für die Benutzer.
herbivore
-
@herbivore
Das erinnert mich an die Bitzählerei, als Speicher knapp und teuer wurde und man am Liebsten alle Dateien gezipt gespeichert hätte. Und heute redet kein Mensch mehr davon. Ebenso die langsame Downloadgeschwindigkeit im Internet. Heute besteht eine Website zu 99% aus Beiwerk und keiner denkt daran, hier etwas zu ändern - mal abgesehen von denen, denen Werbung und blinkende Dekos nicht passen. Und dann gab es noch bitTorrents, um die Last an den Servern zu verringern, in erster Linie aber aus dem Grund, die Downloads schneller zu erhalten.
Heute geht es doch eher anders herum. Die DSL-Geschwindigkeit geht rapide nach oben (außer auf dem Land) und jeder streamt sich seine persönliche Unterhaltung. Daher wäre eine Änderung vom MV vermutlich nur eine kurzfristige Lösung und irgendwann hinfällig.Sicherlich könnte man auf dem Server pro Monat oder Woche eine Liste komplett ablegen und den Rest über Differentlisten erschlagen, das ist aber ein Einschnitt, der auch Änderungen am Client zur Folge hätte. Denn erst einmal müssen die benötigten Listen ermittelt werden und dann eine Lösung für nicht mehr vorhandene Einträge implementiert werden.
-
Hallo MenchenSued,
Das erinnert mich an die Bitzählerei
ich bin ein bisschen verblüfft, denn ich bin davon ausgegangen, dass es im Interesse der Entwickler und Projektbeteiligten liegt, die Serverkosten im Rahmen zu halten und am besten zu senken. Im Zusammenhang mit den (steigenden) Serverkosten habe ich jedenfalls schon mehrfach Spendenaufrufe gelesen. Habe ich da etwas missverstanden?
Änderungen am Client
Mein Vorschlag zielt ja gerade darauf, dass man an Server und Client möglichst wenig ändern muss. Der vorhandene Code für das Erstellen und das Laden von Differenzlisten könnte weiterverwendet werden. Es braucht lediglich ein bisschen zusätzliche Logik bei der Auswahl der zu generierenden bzw. zu ladenden Listen.
Die DSL-Geschwindigkeit geht rapide nach oben
Um Bandbreitenproblme der einzelnen Benutzer ging es mir nicht.
herbivore
-
@herbivore
Ich wollte damit nur zum Ausdruck bringen, dass Serverplatz und Download-Volumen bald für lau zu bekommen sein könnten. Und da ist die Frage, ob sich der Aufwand lohnt.
Für die meisten Anwender wäre es eh besser, nur eine reduzierte Liste zu laden, beispielsweise der letzten 7 Tage. Denn wen interessieren schon die alten Kamellen, wären da nicht die Wiederholungen, die oft leider nicht unter dem aktuellen Datum in der Liste stehen. -
@menchensued sagte in Exakt passende Differenzlisten:
dass Serverplatz und Download-Volumen bald für lau zu bekommen sein könnten.
Kannst Du mir bitte mitteilen in welcher Glasskugel Du das gelesen hast? Würde sicher den ein oder anderen im Controller Hosting Bereich interessieren.
-
@herbivore Naja Diff-Listen haben diverse andere Probleme die sich nicht so schnell lösen lassen da sie nicht ohne weiteres in das Client und Server Konzept hinein passen. Wir arbeiten aber an einer Lösung des Traffic-Verbrauchs der die Nutzbarkeit von MV aber nicht groß einschränken soll/darf. Das größere Problem meines Erachtens sind zur Zeit “schwarze Schafe”, die (wahrscheinlich mit irgendwelchen selbstgebastelten Tools) teilweise alle 10 Minuten die komplette Filmliste herunter laden. Leider können wir (noch nicht) viel gegen diese Leute tun. Ein einfaches Drosseln der Bandbreite würde auch andere unbeteiligte treffen. Aber auch da sind wir bei. Es dauert halt ein wenig
-
@menchensued sagte in Exakt passende Differenzlisten:
Entfallende oder stark gesenkte Traffic-Kosten für Cloudflare-Kunden sollen die Attraktivität von Cloud-Diensten unter anderem von IBM und Microsoft steigern
Naja also der Artikel sagt ja grob das Du nicht mehr den Traffic bei Deinem Cloud Anbieter und Deinem CDN Anbieter bezahlen musst sondern nur noch bei Deinem CDN Anbieter. Das ist zwar eine Kosten Reduzierung bedeutet aber nicht das auf einmal alles für “Lau” ist.
-
Hallo DerReisende77,
Es dauert halt ein wenig
das ist überhaupt nicht mein Punkt. Ich hatte gehofft, dass ich bei einem Problem helfen kann, das euch drängt.
Das größere Problem meines Erachtens sind zur Zeit “schwarze Schafe”
Ok, dagegen hilft mein Vorschlag nicht.
da sie nicht ohne weiteres in das Client und Server Konzept hinein passen.
Kannst du vielleicht ein bisschen was zu dem Client-Server-Konzept sagen? Oder gibt es dazu schon eine Beschreibung (die ich nur nicht gefunden habe)?
Ich finde es einen großen Vorteil vom jetzigen Konzept, dass MV lokal arbeitet. Mein (vollkommen legitimes aber eben doch individuelles) Nutzungsverhalten geht dabei nämlich nicht über das Netz und kann daher von niemand überwacht werden. Gerade mit Blick auf Bestrebungen in anderen Ländern finde ich das bedenklich.
herbivore
-
wir arbeiten an einer API, die sich nur die notwendigen Änderungen vom Server holt und dennoch die Möglichkeit bietet, weiterhin mit dem Client (bis auf wenige notwendige Einschränkungen) offline zu arbeiten. Ziel ist es nicht, Nutzer zu überwachen. Das kostet viel zu viel Zeit und Geld, außerdem haben wir nichts davon.
Das System der Differenzlisten ist - sagen wir einfach - sehr rudimentär gestrickt. Es gibt derzeit keine Möglichkeit SICHER festzustellen welchen Daten ein Client hat und welche nicht. Das zu ändern ist aber auch nicht so einfach wie man sich das vorstellt. Zumal ja auch die Serverseite davon betroffen ist. -
Hallo DerReisende77,
Ziel ist es nicht, Nutzer zu überwachen.
ich hab sicher nicht euch gemeint. Sondern die Möglichkeit von Dritten, Daten, die über das Netz gehen, abzufangen. Außerdem wecken Daten, die gar nicht erst anfallen, keine Begehrlichkeiten solcher Dritter.
Es gibt derzeit keine Möglichkeit SICHER festzustellen welchen Daten ein Client hat und welche nicht.
Bei meinem Vorschlag wüsste das der Server schon bzw. muss es - wenn man es so rum sehen will - nicht wissen, denn es wird ja vom Client immer automatisch die passende Differenzliste angefordert. Es gibt also aus Client-Sicht keinen Nachteil gegenüber dem Abrufen der vollen Liste. Lokal würde in beiden Fällen das gleiche (und richtige) Ergebnis erzeugt. Auf mehr kommt es für den Benutzer auch nicht an.
herbivore
-
@herbivore sagte in Exakt passende Differenzlisten:
ich bin ein bisschen verblüfft, denn ich bin davon ausgegangen, dass es im Interesse der Entwickler und Projektbeteiligten liegt, die Serverkosten im Rahmen zu halten und am besten zu senken. Im Zusammenhang mit den (steigenden) Serverkosten habe ich jedenfalls schon mehrfach Spendenaufrufe gelesen. Habe ich da etwas missverstanden?
Das ist sicher immer erstrebenswert, doch halten sich die Kosten momentan in Grenzen. Ich weiß von 6 vServern, die Crawler und Verteiler spielen sowie meinem dedizierten Server, der u.a. MVW, ein Crawler und 2 Verteiler hat. Der Betrieb von MVW ist für mich rein finanziell betrachtet ein Minusgeschäft, das sich jedoch in Grenzen hält. Und aus diesem Grunde weiß ich auch nichts von einem Spendenaufruf.
@alex sind es mehr als 6 vServer?
-
@bagbag es sind 9 vServer aktuell wobei noch Server von mir zusätzlich beteidigt sind.
Das große Problem der diff listen hat @DerReisende77 schon angesprochen, weswegen ich da nicht mehr näher drauf eingehen.
Trotzdem danke für den Vorschlag.
Aktuell ist das Trafficaufkommen bewältigbar, aber wir haben trotzdem den Anspruch es in einem gesunden Rahmen zu halten. Deswegen auch die Überlegungen in Richtung API.
-
Hallo alex,
bitte noch eine kleine Nachfrage aus Interesse: der DerReisende77 hat gesagt, dass es mit den Differenzlisten große Probleme gibt, aber nicht welche. Kannst du die konkreten Punkte bitte kurz anreißen?
Einen Punkt kann ich mir vorstellen. Ich vermute, dass Differenzlisten momentan nur die zusätzlichen Einträge enthalten, aber keine Informationen darüber welche Einträge weggefallen sind. Aus meiner Sicht ein durchaus lösbares Problem. Wenn alle Stricke reißen, könnte man die Differenzlisten sogar (leicht vereinfacht gesagt) mit dem (Unix-)Kommando diff erstellen und mit dem Kommando patch (oder einer entsprechenden Bibliothek lokal) aus der letzten heruntergeladenen Filmliste und der passenden Differenzliste die aktuelle Filmliste erzeugen.
Den anderen Punkt, dass momentan die aktuelle Differenzliste nicht zu der letzten heruntergeladenen (lokalen) Filmliste passt, löst ja gerade mein Vorschlag.
Beides also mit meines Erachtens überschaubarem Aufwand lösbar. Übersehe ich noch weitere Punkte?
Ich respektiere natürlich, wenn ihr einen anderen Weg gehen wollt. ich würds halt nur gerne wissen.
Und so ein API hat natürlich auch seine Vorteile. Und offenbar habe ich ja auch den Druck, den die Hostingkosten auf euch ausüben überschätzt. Ich hatte halt gehofft, eine relativ schnelle Lösung anzubieten, die euch kurzfristig stark entlastet.
herbivore
-
Du hast den Kern in deinem Text schon erwähnt. Es handelt sich um native Kommandos. Wenn du nach Lösungen suchst schaue bitte nach Sachen die in Java geschrieben sind. Die Nutzung von Patch und diff sind für jede Plattform zu pflegen, zu integrieren und zu nutzen. MV ist nicht nur eine Linux Anwendung sondern bedient auch Mac und Windows. Von daher ist eine Java Lösung deutlich zu präferieren.
-
Hallo DerReisende77,
ich bin nicht davon ausgegangen, dass man direkt die Linux-Kommandos verwendet. Natürlich würde man zumindest lokal eine entsprechende Java-Bibliothek nehmen. Ich hab nur kurz geguckt, aber wenn man nach diff patch java library oder ähnlichem sucht, findet man da was.
Ansonsten lässt sich die Differenz auch mit wenig sehr simplem Code berechnen, wenn die zu vergleichenden Listen (temporär) sortiert sind. Das hätte bei Bedarf den Vorteil, dass man die zu löschenden Einträge kompakter speichern kann, z.B. über eine ID oder als Hash.
Klar, bei der Umsetzung gibt es an jeder Stelle ein paar Details zu beachten. Als Programmierer habe ich aber extra darauf geachtet, den Vorschlag so zu gestalten, dass möglich wenig und möglichst einfacher Code ausreicht und gleichzeitig die Komplexität gering ist und wenig Änderungen reichen. Und trotzdem für den Benutzer das Ergebnis exakt gleich ist, nur eben mit (vor allem für euch) deutlich weniger Download-Volumen.
Ich will nicht nerven. Momentan geht es mir nur darum, etwaige Missverständnisse bezüglich des Vorschlags auszuräumen.
herbivore
