Verpasse nichts mehr mit unserer Foren App. zum AppStore

clasherstats.de - was braucht ihr an Infos?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Clasherstats.de schrieb:

      Hallo Slind

      Danke für deine Hinweise!

      OK, Banner ist in Arbeit :)

      Datatables: Bin kein Fan von jquery, weil da ziemlich viel Mist über die Bandbreite geladen wird. Da ich die nächsten Tage bei clasherstats.de die Bandbreite optimieren werde, ist das eher nicht so gedacht.
      Genauso will ich in den nächsten Tag die Möglichkeit schaffen auch bei deaktiviertem JavaScript alle Funktionen der Seite zu nutzen.
      Identisch auch D3, auch hier lässt sich aber die Grafik optimieren :)
      Gibt also noch viel zu tun ;)

      Datenstruktur: Das würde ich ungern so frei plaudern, aber ich hole mir täglich jeweils eine Million Spieler komplett (CWs gehen ja zwei Tage lang, daher wird jeder cw mitgeloggt) und über die Clans mit weniger Daten jeden Spieler täglich (auch clanlose). Insgesamt recht kompliziert, aber mit dem positiven Effekt, dass keiner verloren geht ;)
      Die Datenbank ist normalisiert. Daher laufen dann die Datenbankabfragen noch schnell, eher habe ich Geschwindigkeitsprobleme bei der API, aber mal schaun, wie ich die noch optimiere ;)
      Auch die Datenbankgröße hält sich in Grenzen, nach aktueller Prognose muss ich in 3 Jahren auf eine größere SSD ziehen und in 5 Jahren muss ich hoffen, dass es bis dahin noch größere SSDs gibt :) Oder alternativ die historischen Daten trennen in Jahre oder oder oder oder

      Gerne können wir clasherstats.de mit dem Forum verbinden, das sollte ja prima machbar sein. Lass uns das mal am Besten persönlich besprechen: [email protected] ;)

      Viele Grüße

      Ben
      Das kann ich so beim besten Willen leider nicht unterschreiben. Du musst bedenken, wenn du jquery über einen stark verwendeten CDN einbindest ist die Wahrscheinlichkeit, dass dies bereits gecached im Browser zur Verfügung steht extrem hoch, wodurch kein weiterer Traffic weder für dich noch den Client anfällt. Selbes gilt mit Datatables und D3. Während beide nicht so oft wie jquery zum Einsatz kommen ist Verwendung immer noch hoch und Wahrscheinlichkeit, das es gecached vorhanden ist, nicht gering.

      Insbesondere bei D3 vs Bilder, hast du enorme Einsparungsmöglichkeiten was Traffic anbelangt.
      D3 liegt bei einer Dateigröße von 78 KB und benötigt keine weitere lib. Ein einziges Bild von dir liegt bereits bei ~20 KB. Zudem bindest du bereits auf der Startseite 6 Stück davon ein und die werden noch nicht einmal gecached.

      Also 3 Seitenaufrufe im Schnitt:

      D3 = 78.1 KB
      Bildergrafiken = 20 KB * 6 * 3 = 360 KB
      => ~461%

      Eine Einsparung von 461%, das musst du erst mal mit deinen anderen Vorhaben zur Traffic Verringerung schaffen. (Dies berücksichtigt jetzt natürlich nicht die Daten selber, aber bei 3 Integern pro Grafik die zudem mit dem Document geschickt werden ist das zu vernachlässigen und spart am Ende sogar noch mehr, da es keine weiteren requests (für jedes Bild) gibt)

      Bei der Tabelle und Datatables ist dies natürlich nicht der Fall, ja da würde etwas mehr Traffic anfallen, aber nachdem du aktuell die ganze Seite neu lädst sobald man den Filter verwendet und da man für die Sortierung die Seiten wechseln muss und zudem alle Bilder von Anfang an geladen werden (auch die im nicht sichtbaren Bereich), rechnet sich dies nach 3-4 Seitenaufrufen bzw. Filterungen sofort. Wobei wenn du nur die Bilder im sichtbaren Bereich mit Datatables lädst, rechnet sich dies schon mit dem ersten Aufruf.

      Nochmal als Rechnung bei 5 Sortierungen/Filterungen im Schnitt (bedenkt JQuery ist meist bereits gecached vorhanden):

      JQuery + Datatables: 38.8 KB + 27.7 KB = 66.5 KB
      Document: ~12.2 KB * 5 = 61 KB
      => ~ -9%

      Rechnet man nun mit ein, dass JQuery bei 80% der Anfragen bereits vorhanden ist und Datatables bei 10%, sieht das Ganze schon ganz anders aus. Zudem betrifft dies natürlich auch wiederkehrende Nutzer von denen die Seite vermutlich einige haben wird. Des Weiteren sollte man vor allem bei mobilen Nutzern die Seitenladezeit nicht außer Betracht lassen, denn bei Datatables findet die ganze Sortierung lokal statt.

      Jedoch, setzt dies voraus, dass alle Daten bereits mitgeliefert werden (was bei 110k Clans nicht der Fall sein wird) wodurch ein Ajax Call für neue Daten beim Filtern noch zusätzlich ins Gewicht fällt.

      Hier stimme ich dir also Absolut zu, hier gibt es keinen Gewinn was Traffic anbelangt. Jedoch würde ich empfehlen die Tabellen direkt sortierbar zu machen (Klick auf die Spalte) und die Daten mit Ajax nachzuladen um Traffic und Ladezeit zu sparen.


      Bei der Datenstruktur Frage gab es wohl Unklarheiten. So schön Normalisierung ist, so hat es auch den Nachteil, dass es nicht skaliert. Die Dauer der Anfragen verlangsamt sich vermutlich jeden Tag. Deswegen bin ich gespannt wie lange das noch gut geht, insbesondere wenn die Anfragen zunehmen und die Daten nicht intelligent gecached werden. Ich würde bei der Menge an Daten vermutlich auf eine de-normalisierte MongoDB setzen.

      Ich habe schon recht viel mit normalisierten Session Datenbanken gemacht, bei denen es darum ging ein ganzes Jahr zu veranschaulichen. Da ist man mit 100 Millionen Zeilen, MySQL, normalisiertem Schema, 5 benötigten Joins/SubQueries und Gruppierung nach Tagen mit Berechnung von einzelnen Sessions zu Tages Zahlen trotz Cluster schnell am Ende.
    • Community Video von MM am Start Zum vollständigen Video
    • Ben also ich finde es Klasse, wenn ich einen Clan suchen würde.
      Super Leistung
      Habt ihr Interesse an einem Dauerkriegsclan, bei dem der Spaß im Vordergrund steht? Sucht ihr aber auch strukturierte Formen?
      Wenn euer RH zum Level passt, dann seid bei
      Braveheart
      willkommen.
      Clan ID #Q29U98RL
    • Slind schrieb:

      Jedoch, setzt dies voraus, dass alle Daten bereits mitgeliefert werden (was bei 110k Clans nicht der Fall sein wird) wodurch ein Ajax Call für neue Daten beim Filtern noch zusätzlich ins Gewicht fällt.

      Hier stimme ich dir also Absolut zu, hier gibt es keinen Gewinn was Traffic anbelangt. Jedoch würde ich empfehlen die Tabellen direkt sortierbar zu machen (Klick auf die Spalte) und die Daten mit Ajax nachzuladen um Traffic und Ladezeit zu sparen.

      Mhm, diese beiden Passagen hebeln deinen ganzen Text aus. Direkt sortierbar bedeutet: aus X Ranglisten wird 1 Rangliste, der Benutzer versteht nicht, welche Möglichkeiten er hat. Zwei Gründe, warum es bei so vielen Ranglisten bleiben sollte, habe die Sortierbarkeit extra rausprogrammiert.
      Unabhängig von dem Inhalt sind deine Rechnungen auch sehr geschönt bzw. Wie die Benzinverbrauchswerte auf Listen bei Neuwagen, nur unter Optimalbedingunen, die es nicht in der Realität gibt, erreichbar.

      Zu jquery: Das ist gerade so, wenn ein Formel1-Rennfahrer und ein Radrennfahrer sich unterhalten, ob ein Auto oder ein Fahrrad besser ist. Alles hat seine Vorteile, alles hat seine Nachteile, besonders auf die Frage vom Einsatzgebiet (Stadt oder Wochenendpendler). Sicherlich wird eine jquery bei mir nicht von einem fremden Server geladen, sicherlich schicke ich nicht 100 oder 200KB Dateien zum Client, nur um 1KB oder noch weniger davon auch wirklich zu nutzen, wenn es anders auch funktioniert. Die gleiche Situation haben C++ler, wenn sie mit Java-Programmierern sprechen.
      Ziel ist es auch eine Möglichkeit für JavaScript-Deaktivierer zu ermöglichen clasherstats.de zu nutzen, da ist eine Umstellung auf JavaScript etwas hinderlich. Genauso habe ich schon Lüfter gehört, weil ein paar Webseiten angezeigt wurden. Als ich näher nachschaute, merkte ich, dass JavaScript meinen PC lahmlegte, nicht nur weil schlecht programmiert.
      Die Vorteile kannst sicher du besser aufzählen ;) Ist aber für mich ein anderes Thema :)

      Zur Datenbank:
      Beruflich bin ich auch Programmierer, habe schon heftige Datenbanken verwaltet. 100 Milionen Werte sind ein Witz. Wir haben jeden Tag von 2 Millionen Spielern Daten, ab 1.1. laufen die Werte. Jeder kann jetzt zusammenaddieren, wie viele Werte das gesamt sind. Geschwindigkeitsengpass ist nicht die Datenbank gerade, sondern die Schnittstelle, werde das optimieren.
      - 5 benötigte Joins/Subquery: gibt es hier nicht
      -- sehr wenige joins vorhanden, wenn nur einzelne (außerhalb Schnittstelle und Wartungsskripte)
      - Gruppierung nach Tagen -> gibt es hier nicht
      - Berechnung von einzelnen Sessions zu Tages Zahlen -> gibt es hier nicht
      Ungern möchte ich näher auf die Technik eingehen, aber mich ist er die Datenbankgröße das Problem und dass es auf SSD parken muss.
      Die einzigen öffentlichen starken Abfragen sind bei Statistik und auch da werde ich noch Optimierungen vornehmen, nicht nur technisch.
      Auch muss man verstehen wie Indexe funktionieren und wie man Indexe aushebelt, dann werden das natürlich deutlich weniger Datensätze, die überprüft werden.

      Die große Kernfrage ist, wofür was eingesetzt wird:
      MySQL -> Datenlager
      PHP -> Datenverarbeitung
      HTML -> Datenausgabe
      CSS -> Design
      JavaScript -> minimale Anpassungen (Uhrzeit mitlaufen lassen, kleine Nachladungen, etc.)
      Wenn man sich an diese Grundregeln hält, dann sind die von die beschriebenen Probleme vermeidbar.

      @ Willian: danke :)

      Viele Grüße

      Ben
      clasherstats.de - Statistiken und Ranglisten rund um COC, jetzt mit Auto-CW-Reservierungstool
    • Clasherstats.de schrieb:

      Unabhängig von dem Inhalt sind deine Rechnungen auch sehr geschönt bzw. Wie die Benzinverbrauchswerte auf Listen bei Neuwagen, nur unter Optimalbedingunen, die es nicht in der Realität gibt, erreichbar.
      In wie weit sind sie geschönt? Bei Datatables ist es klar, das ist durch JQuery recht groß und da ist dein aktuelles Skript um einiges kleiner, zudem war von der Nutzung ohne Javascript keine Rede zuvor.

      Bei den Bildern als Graphen ist dies aber doch ziemlich ausschlaggebend, da fallen am Ende ja nicht nur die Größe der Bildern sondern auch die zusätzlichen Network Requests ins Bild.

      Ich hätte mir bei den den Daten gedacht, dass sich dies über einige Table hinweg aufteilt, wenn es nur so wenige Joins braucht und keine Gruppierungen dann ist das bei richtig gesetzten Indexen verständlich kein Problem. Ich habe mir da die Datenstruktur komplexer vorgestellt.
    • Ja, das gilt es noch zu optimieren :)
      Am Server sind es gerade 0,8 - 1,3 Sekunden. Eine API-Anfrage alleine hat davon rund 0,6 Sekunden. Der Rest geht für Diagramme, etc. Drauf. Warum die Weitergabe so lange ist, weiß ich gerade noch nicht, aber die ersten Zahlen lassen sich noch optimieren ;)
      Natürlich, wenn die Diagramme lokal geladen werden, dann ist die Ladezeit vom Server und auf dem Weg zum Client geringer, aber dann muss der Client das noch tun, was ja nicht in die Zeit mit hineingeht.

      Auch die Schnittstellen optimiere ich gerade, dass sie a) so viele wie möglich so schnell wie möglich aktualisieren (Statistiken werden dazu ab Wochenende veröffentlicht) und b) trotzdem noch so schnell wie möglich die Seiten ausgeliefert werden.

      Bei den neuen Forengrafiken gab es noch einen optischen Fehler, das ist inzwischen bereinigt ;)
      clasherstats.de - Statistiken und Ranglisten rund um COC, jetzt mit Auto-CW-Reservierungstool
    • Worin siehst du den Wert die Graphen über Bilder auszuliefern?

      Das mit dem Table verstehe ich ja aber bei den Graphen sehe ich keinen Sinn in der Auslieferung über Bilder.

      Die Berechnung am Client hat natürlich den Vorteil dass es den Server entlastet was sich bei viel Traffic ohne Cluster auch auf die Ladezeit auswirken kann.

      In Zeiten von Angular, Ember und React ist dies ja mehr als üblich.
    • Naja, beruflich programmiere ich innerhalb einer Branche, wo es auch mal nett ist die Grafiken abzuspeichern, eine Seite als PDF (serverseitig) zu generieren, etc. Die Verlässlichkeit beim Server ist da deutlich höher als beim Client.

      Natürlich, bei einer Statistikseite mit nicht enorm kritischen Daten ist das nicht so wichtig, daher werde ich auch sicherlich demnächst in Erwägung ziehen dies anzupassen, da die Grafiken auf dem Server generiert und abgespeichert werden und DANN erst an den Client geschickt werden. Zudem sind Grafiken aus meiner Sicht zumeist nicht in der MustHave-Liste, wenn z.B. JavaScript deaktiviert ist bzw. Wenn jemand mit einem Textbrowser irgendwann fehlende Grafiken bemängeln würde, hätte ich damit kein Problem ^^
      Steht aber nicht auf der Prio 1 - Liste :D

      Da ist natürlich die Frage, warum nicht gleich so? Ganz einfach: vor drei Wochen gab es noch nicht eine Zeile Code, oder ähnliches. Einige Dinge habe ich von bestehenden Projekten übernommen und angepasst, andere Dinge komplett neu entwickelt und zwar neben dem Beruf und dem restlichen Leben. Und dafür sind wir ja schon ziemlich weit :D
      clasherstats.de - Statistiken und Ranglisten rund um COC, jetzt mit Auto-CW-Reservierungstool
    • Hey,

      dir scheint die Diskussion zu gefallen, aber du bist nicht angemeldet.

      Wenn du ein Konto eröffnest merken wir uns deinen Lesefortschritt und bringen dich dorthin zurück. Zudem können wir dich per E-Mail über neue Beiträge informieren. Dadurch verpasst du nichts mehr.


      Jetzt anmelden!