Wäre es im Bereich des Möglichen, dass ihr da so etwas wie ein Tagebuch drüber schreibt? Würde mich freuen ein wenig detaillierter mitzubekommen, wie Dotasource funktioniert.
Angepinnt DotaSource Reborn
-
-
Ich glaube unsere Jungz haben noch genug zu tun, als Protokoll darüber zu führen was sie machen.
-
Ah, danke an das Oberhaupt des Staffs für diese offizielle™ Mitteilung in ihrem Namen. Danke Matlok.
-
Dann führe ich das noch einmal für dich aus.
Die Administratoren haben eine TODO Liste, die sie noch komplett abarbeiten müssen. Die bekommen kein Geld dafür und dennoch kommen jeden Tag neue Wünsche, Beschwerden und Bugs hinzu. Wenn sie jetzt noch jeden Schritt protokollieren würden, wäre das noch mehr Arbeitszeit, die sie stattdessen in sinnvollere Projekte stecken könnten. Ganz abgesehen von der Tatsache, dass wenn sie das Protokoll jetzt erst anfangen würden, schon vieles fehlen würde. Wäre ein nettes Gimmick, lieber luke, aber ich denke nicht machbar. Vielleicht kann ich mich auch irren.
Das war keine offizielle Mitteilung, sondern meine Sicht der Dinge. Ich bin auch nicht Oberhaupt des Staffs, mein jetziger Titel ist ironischer Natur (Bundesländerclashvergesser™ war das zum Beispiel nicht). Ich wünsche dir frohe Weihnachten. -
@ramius gibt's ne Möglichkeit den Quellcode von Posts anzeigen zu lassen (so wie früher)? Wenn man gequotete Sachen copy&pasten will ist das immer ein riesen abfuck. genauso wie löschen von zitierten Inhalten.Byron - Attributmagier
Der Korpothread
Oster schrieb:
Wenigstens shrodo denkt mit.
"some games just feel so unthrowable until you suddenly lost" -
Wechseln in den BBCode Editor hilft dabei!
till the end -
Wow danke. dachte immer das ding ganz rechts wär nur deko
m-u-h schrieb:
Wechseln in den BBCode Editor hilft dabei!
Byron - Attributmagier
Der Korpothread
Oster schrieb:
Wenigstens shrodo denkt mit.
"some games just feel so unthrowable until you suddenly lost" -
In erster Linie interessiert mich die codeseitige Umsetzung. zB die PHP-Optimierung, die B2F angesprochen hat, oder was er mit dem auslagern von statischem Content über nginx meint. Dass Ihr ein explizites Tagebuch führt erwarte ich gar nicht, mir würden schon eure Commit-Meldungen genügen
ramius schrieb:
Meinst du speziell im Bezug auf die Performance, was B2F gerade angesprochen hat, oder auch auf Funktionen? Im Grunde sprechen wir es ja hier im Thread immer an, wenn etwas von der TODO Liste abgearbeitet wird oder wir unabhängig von der Liste Änderungen vornehmen. Ein explizites Tagebuch werden wir wohl nicht führen, aber wir listen die meisten der Änderungen mindestens in einem Nebensatz auf und sollten Fragen, auch zur technischen Natur oder der codeseitigen Umsetzung aufkommen, kannst du / könnt ihr sie gerne stellen. Da man allerdings zu selbst kleinen Änderungen häufig einen ganzen Roman schreiben kann, ist es denke ich sinnvoller, auf Nachfrage etwas im Detail auszuführen. Es kann jedoch manchmal dauern, bis wir auf die Frage eingehen, da Matlok richtig liegt, dass wir nicht immer die Zeit dafür haben oder sie in dem Moment anderweitig nutzen möchten.luke schrieb:
Wäre es im Bereich des Möglichen, dass ihr da so etwas wie ein Tagebuch drüber schreibt? Würde mich freuen ein wenig detaillierter mitzubekommen, wie Dotasource funktioniert.
-
Und das ist eben auch mein Argument die Sachen selber zu hosten. Da nach dem ersten mal Laden die Skripte, auch wenn sie auf ds.de gehostet werden, im Cache sind (bei entsprechender config). Und da ds.de kaum first-time-loads hat, sondern hauptsächlich wiederkehrende User, ist das denke ich von dem Aspekt her der erste Seitenaufruf vernachlässigbar und für mich spricht dann nichts dafür Skripte auszulagern, weil das das Riskio nur streut. Dafür habt ihr aber auch mehr Traffic.
B2F schrieb:
Das kommt drauf an, worauf man Wert legt. Auf der einen Seite kann das Einbinden von externen Resourcen tatsächlich zu einer höheren Latenz führen. Aber da die Skripte, die von extern eingebunden werden, immer die selben sind (jQuery, Google Fonts) hat ein Client maximal ein Mal das Problem dieser höhen Latenz. Danach wird die Datei aus dem Cache geladen und hat quasi keine Latenz mehr.watnuss schrieb:
Stimmt leider nicht ganz. Ist eigentlich nicht so clever so scripte (auch ajax.googleapis.com) auszulagern, da das den roundtrip erhöht. Ich hab da ne coole Präsentation zu gesehen, vll find ich das. Die Quintesenz letztlich ist das die kompletten Metriksysteme der IT fürn Arsch sind, weil sich da nur Percentile/Mittelungen etc. angeschaut werden. Tatsächlich ist aber das langsamste Paket ausschlaggebend für den Seitenaufbau. Und wenn bei nem Seitenaufbau zu viele Quellen aufgerufen werden, ist die Chance dafür, dass eines davon gerade zufällig ne schlechte Latenz hat ziemlich hoch. Am Ende sind dann über 50% der page refreshes (trotz caching) spürbar langsam.
Allgemein denke ich aber nicht, dass das Problem am Caching liegt, da ja auch bei folgenden Seitenaufrufen eine spürbare Latenz zu bemerken ist. Auf jeden Fall im Kontrast zur alten Software. Denke das das Problem eher schwer zu lösen sein wird, da es mit der Komplexität der Software einher geht. Je mehr Ressourcen ich einbinde, desto länger der Seitenaufbau.
Oder ein anderes Beispiel: Die Anzahl der Smilies. Je mehr Smilies angeboten werden desto eher habe ich viele unterschiedliche Smilies auf der Seite eines random Threads. Jeder Smily der da geladen wird ist ein weiterer HTTP Request. Je mehr Request desto wahrscheinlicher ein Ausreißer, der länger braucht und desto länger der maximale Seitenaufbau.
Ist halt auch keine Lösung jetzt ne Seite ohne Javascript und CSS zu bauen und will ich hier auch nicht vorschlagen. Nur die Ursache liegt für mich eher in diesem Bereich. (Ohne jetzt viel Zeit ins Testen investiert zu haben).There are 10 types of people - those who understand binary, and those who don't. -
ich glaub das risiko, dass die google-server faxen machen, ist vernachlässigbar. kann mich nicht erinnern, je ein langsames google erlebt zu haben.
eventually there comes a point where it's like the true test for your team - will he cast a spell or will he not
- Artour Babaev
Und wenn beide dann nicht mehr stacken und der einer 6k Boi, der vorher 4k war, mit einem anderen 4k Boi spielt, dann ist er nicht mehr 6k, weil er reverse trägert, oder?
- User des Monats -
Darum geht es nicht, sondern darum, dass du Pakete hast, die n ganz anderen Weg gehen/anders Routing haben als der Rest.
Und ich kann mich an ne Google Downtime von 1-2h erinnern vor 1-2 Jahren, bei der dann das halbe WWW kaputt war, weil jede 2. Seite Google AdSense nutzt.There are 10 types of people - those who understand binary, and those who don't. -
kann mir doch egal sein, so lang das nicht länger dauert, oder habe ich da was missverstanden?
so wie ich deinen vorherigen vorhandenen post verstanden habe, war die kernaussage, dass es eine schlechte idee ist, sachen von vielen verschiedenen servern zu beziehen, weil sich dadurch die wahrscheinlichkeit erhöht, dass einer von denen zum zeitpunkt meiner anfrage gerade aus irgendeinem grund lahm ist. wenn man das risiko bei einem server aber nahezu ausschließen kann, ist es doch total wumpe? inwiefern ist denn der weg des paketes relevant?
eventually there comes a point where it's like the true test for your team - will he cast a spell or will he not
- Artour Babaev
Und wenn beide dann nicht mehr stacken und der einer 6k Boi, der vorher 4k war, mit einem anderen 4k Boi spielt, dann ist er nicht mehr 6k, weil er reverse trägert, oder?
- User des Monats -
Aber es kommt doch zu gar keinem Routing zu den Google Servern, da die Dateien bei dir im Cache liegenwatnuss schrieb:
Darum geht es nicht, sondern darum, dass du Pakete hast, die n ganz anderen Weg gehen/anders Routing haben als der Rest.
das gleiche gilt für die Smileys. -
der browser schickt aber doch trotzdem eine anfrage, ob der kram noch aktuell ist?!
eventually there comes a point where it's like the true test for your team - will he cast a spell or will he not
- Artour Babaev
Und wenn beide dann nicht mehr stacken und der einer 6k Boi, der vorher 4k war, mit einem anderen 4k Boi spielt, dann ist er nicht mehr 6k, weil er reverse trägert, oder?
- User des Monats -
ne, oder? dafür sind doch die expire date header
-
was genau tut dann mein browser hier?
sieht bei jedem f5 genau so aus
eventually there comes a point where it's like the true test for your team - will he cast a spell or will he not
- Artour Babaev
Und wenn beide dann nicht mehr stacken und der einer 6k Boi, der vorher 4k war, mit einem anderen 4k Boi spielt, dann ist er nicht mehr 6k, weil er reverse trägert, oder?
- User des Monats -
Eine Datei, die im Cache liegt mit entsprechenden Expires Headern verursacht keinen neuen HTTP request, auch nicht um zu überprüfen, ob die Datei verändert wurde. (Zumindest so lange man sich normal durch eine Seite klickt, Chrome beispielsweise checkt bei drücken von F5 schon ob die Dateien verändert wurden.) Die jQuery-Datei kann durch den Besuch einer komplett anderen Website bereits im Cache vorhanden sein.watnuss schrieb:
Und das ist eben auch mein Argument die Sachen selber zu hosten. Da nach dem ersten mal Laden die Skripte, auch wenn sie auf ds.de gehostet werden, im Cache sind (bei entsprechender config). Und da ds.de kaum first-time-loads hat, sondern hauptsächlich wiederkehrende User, ist das denke ich von dem Aspekt her der erste Seitenaufruf vernachlässigbar und für mich spricht dann nichts dafür Skripte auszulagern, weil das das Riskio nur streut. Dafür habt ihr aber auch mehr Traffic.
Ich denke das ganze ist mehr oder weniger vernachlässigbar wo diese wenige Dateien im Endeffekt gehostet sind..
Die kritischen Optimierungen liegen momentan bei der Latenz zwischen aufrufen einer Seite und Antwort des Servers. Auf der anderen Seite braucht der Browser seit dem Update auch wesentlich länger für den Aufbau der Seite.
F5 sorgt wie oben geschrieben für einen check, ob der kram noch aktuell ist. Klicke mal auf einen Link, statt F5 zu nutzen.lustigerbilderposter schrieb:
sieht bei jedem f5 genau so aus
-
Der Unterschied in den Aussagen ist, dass der lahmende Googleserver nur eine Ursache unter vielen für ne verlängerte Paketlaufzeit ist. Es kann praktisch jede Netzwerkkomponente auf dem Weg vom Server zu dir für einen hiccup verantwortlich sein.lustigerbilderposter schrieb:
kann mir doch egal sein, so lang das nicht länger dauert, oder habe ich da was missverstanden?
so wie ich deinen vorherigen vorhandenen post verstanden habe, war die kernaussage, dass es eine schlechte idee ist, sachen von vielen verschiedenen servern zu beziehen, weil sich dadurch die wahrscheinlichkeit erhöht, dass einer von denen zum zeitpunkt meiner anfrage gerade aus irgendeinem grund lahm ist. wenn man das risiko bei einem server aber nahezu ausschließen kann, ist es doch total wumpe? inwiefern ist denn der weg des paketes relevant?
Per expired/max-age caching ja. Dennoch erzeugen sie einen HTTP request, da ja gegen diese Daten gecheckt wird. Dann ist eben nicht das Routing/Netzwerklatenz das Problem, sondern interne Prozesse auf dem Clientsystem. Ein HTTP Request pro Ressource wird immer "abgeschickt".ramius schrieb:
Aber es kommt doch zu gar keinem Routing zu den Google Servern, da die Dateien bei dir im Cache liegenwatnuss schrieb:
Darum geht es nicht, sondern darum, dass du Pakete hast, die n ganz anderen Weg gehen/anders Routing haben als der Rest.
das gleiche gilt für die Smileys.
There are 10 types of people - those who understand binary, and those who don't.