nicht angemeldet
Der Martin
Der Martin
MudGuard
MudGuard
Der Martin
Der Martin
robertroth
Der Martin
robertroth
Hallo,
ich habe das dumpfe Gefühl, es besteht immer noch erheblicher Optimierungsbedarf bei der Forensoftware bzw. deren Web-Schnittstelle.
Mir fällt immer wieder unangenehm auf, dass selbst das Laden der Forenübersicht http://forum.selfhtml.org/ ziemlich lange dauert (andere Seiten natürlich auch). Mein Opera, der in der Fortschrittsanzeige beim Laden sowohl die verstrichene Zeit, als auch die übertragene Datenmenge live mitzählt, kommt für die genannte Übersichtsseite regelmäßig auf über 30, manchmal sogar über 40 Sekunden und rund 1.2MB.
Inzwischen habe ich die Ressource http://forum.selfhtml.org/application-435e2eab22e5fc9b9cbc7633efb70856ed7c9059c05d017169d52b1d2b61f563.js als Übeltäter ausgemacht. Die hat allein etwa 1.1MB und kommt nur sehr, sehr langsam über den Draht. Ein isolierter Request auf diese Ressource mit wget weist eine Ladezeit von 38s aus. Das entspricht dem Tempo eines alten Telefonmodems bei schlechter Verbindung.
Und anscheinend wird diese Ressource auch nicht gecacht, oder wenn, dann nur für sehr kurze Zeit, denn sie wird bei nahezu jedem Seitenabruf wieder neu übertragen. Sowohl von meinem alten Opera, als auch vom Firefox auf meinem Rechner, als auch vom Firefox auf dem Rechner eines Kunden, auf dem ich nur eingeschränkter User bin und auch den Firefox weitgehend in der Defaultkonfiguration nutze.
Vor allem das Nicht-Cachen ist für mich rätselhaft, da die Header doch eigentlich eine ordentliche Cache-Dauer empfehlen, wie ein Auszug aus der LiveHTTP-Extension zeigt:
GET /assets/application-435e2eab22e5fc9b9cbc7633efb70856ed7c9059c05d017169d52b1d2b61f563.js HTTP/1.1
Host: forum.selfhtml.org
[...]
Accept: */*
Accept-Language: en-us,en;q=0.7,de;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://forum.selfhtml.org/
[...]
Connection: keep-alive
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Fri, 08 May 2015 11:20:55 GMT
Content-Type: application/x-javascript
Content-Length: 1112156
Connection: keep-alive
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000, public
Accept-Ranges: bytes
Interessant finde ich, dass meine Browser bei sämtlichen untergeordneten Ressourcen (Bilder, Stylesheets) brav mit einem If-Modified-Since-Header anfragen, dann erwartungsgemäß ziemlich flott ein "304 Not Modified" als Antwort bekommen - nur bei dem oben erwähnten Javascript-Monster geht immer ein bedingungsloser Request raus, der mit 200 und der vollen Datenmenge beantwortet wird.
Warum?
So long,
Martin
Hallo Martin,
sei mir nicht böse, ich bin mir ziemlich sicher, dass das Problem auf deiner Seite liegt. Selbst mit meiner popeligen 9mbit-Leitung bekomme ich die Ressource mit 900kb/s und in unter 2 Sekunden (bei 100 Requests auf die Ressource 1.433s im Schnitt, ich hab einfach in einem Shell-Script 100 mal curl drauf geschickt). Auch gecached wird die Datei bei mir einwandfrei. Chrome und Firefox, Linux und OS X.
Ansonsten kann ich dir nur raten Paging wieder zu aktivieren. Es hat seinen Grund, dass ich das eingeführt habe ;-) Die Hauptseiten profitiert unglaublich davon, Rails ist nicht besonders gut darin sehr viele Objekte zu rendern.
Edit: auch andere User (ich hab mal im Bekanntenkreis gefragt) haben dein Problem nicht. Die Datei wird sowohl gecached als auch mit hoher Geschwindigkeit ausgeliefert.
Edit 2: im Schnitt ist eine Seite bei mir nach 700ms geladen und überträgt 8kb.
Edit 3: die JS- und CSS-Files sind bei mir seit gestern, 12:28 nicht mehr angefordert worden
LG,
CK
Hallo,
sei mir nicht böse, ich bin mir ziemlich sicher, dass das Problem auf deiner Seite liegt.
will ich nicht ausschließen, aber da es eben nicht nur bei mir zuhause auftritt, sondern auch bei meinem Kunden über dessen Firmennetz, kann ich das noch nicht so ohne Zögern akzeptieren.
Und wenn's nur die Browser wären, könnte ich auch noch hinnehmen, wenn einer sagt, ich hätte eine total unübliche oder verkorkste Konfiguration. Aber auch wget von der Kommandozeile lädt die Ressource ja nur ganz gemütlich im Schneckentempo, und das auf drei Rechnern hier im Netz etwa gleich. Die Ladezeiten variieren zwischen etwa 30 und manchmal bis über 50s. Übrigens an einem 6Mbit-DSL-Anschluss, wo ich sonst zwischen 300 und 750kB/s erreiche, je nachdem, wie schnell die Gegenseite liefert.
Ansonsten kann ich dir nur raten Paging wieder zu aktivieren.
Nicht, solange ich nicht dazu gezwungen bin. Dass die Thread-Listen etwas Zeit zum Laden brauchen, akzeptiere ich ja gern, die lade ich auch nur in etwas größeren Zeitabständen neu.
Aber das hat nichts mit dem beschriebenen Problem zu tun, denn das tritt ja eben auch bei der Foren-Übersicht (Domain-Root) und beim Aufrufen eines Einzelbeitrags auf.
Edit: auch andere User (ich hab mal im Bekanntenkreis gefragt) haben dein Problem nicht. Die Datei wird sowohl gecached als auch mit hoher Geschwindigkeit ausgeliefert.
Ist mir rätselhaft.
Wie gesagt: Wenn du meinst, das Problem läge bei mir, dann gib mir doch bitte Anhaltspunkte, woran es liegen könnte. Und bedenke dabei, dass das beschriebene Problem auf mehreren PCs und einem Raspberry Pi in gleicher Weise auftritt, aber nur auf diese eine Ressource beschränkt ist. Wenn "das gesamte Internet" so lahm wäre, könnte ich noch meine Fritzbüx verdächtigen. Aber andere Ressourcen kommen mit ordentlichem Tempo rein.
Für Anhaltspunkte bin ich dankbar.
Ergänzung: Das Aufrufen der Vorschau für dieses Posting ging zwischendurch ruck-zuck, d.h. in gefühlt unter zwei Sekunden, obwohl da dieselbe Ressource eingebunden ist. Es geht also ab und zu auch schnell.
So long,
Martin
Hallo Martin,
vorweg: ich hatte völlig vergessen minifying zu aktivieren. Das habe ich jetzt nachgeholt, dadurch ist die Dateigrösse auf 500kb runter. Dazu habe ich GZip compression wieder aktiviert, damit bin ich auf ca 150kb runter.
Und wenn's nur die Browser wären, könnte ich auch noch hinnehmen, wenn einer sagt, ich hätte eine total unübliche oder verkorkste Konfiguration. Aber auch wget von der Kommandozeile lädt die Ressource ja nur ganz gemütlich im Schneckentempo, und das auf drei Rechnern hier im Netz etwa gleich. Die Ladezeiten variieren zwischen etwa 30 und manchmal bis über 50s. Übrigens an einem 6Mbit-DSL-Anschluss, wo ich sonst zwischen 300 und 750kB/s erreiche, je nachdem, wie schnell die Gegenseite liefert.
Verwirrend, denn ich bin mir sicher, dass ich mit 900kb auch über längere Zeit ziehen kann (ich hole mir gelegentlich einen Datenbank-Dump, um aktuelle Test-Daten zu haben). Und von anderen habe ich auch keine Beschwerden diesbezüglich gehört, wie gesagt, ich habe extra nachgefragt nach deinem Posting.
Wie gesagt: Wenn du meinst, das Problem läge bei mir, dann gib mir doch bitte Anhaltspunkte, woran es liegen könnte.
Das kann ich nicht. Ich kenne ja deine Umgebung nicht wirklich und anhand deiner Beschreibung stehe ich vor einem ähnlichen Rätsel wie du. Ich kann nur eins sagen:
Hat dein Opera vielleicht eine Obergrenze für Cache-Entries und er cached sie deshalb nicht?
LG,
CK
Hi,
Und von anderen habe ich auch keine Beschwerden diesbezüglich gehört, wie gesagt, ich habe extra nachgefragt nach deinem Posting.
Was bei mir immer (oder fast immer, ich achte nicht immer darauf) der Fall ist: nachdem die Seite geladen ist, steht noch ewig lange "Waiting for node.forum.selfhtml.org..." in der Statuszeile meines Firefox.
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
Was bei mir immer (oder fast immer, ich achte nicht immer darauf) der Fall ist: nachdem die Seite geladen ist, steht noch ewig lange "Waiting for node.forum.selfhtml.org..." in der Statuszeile meines Firefox.
Ja, das liegt an dem dämlichen Node-Server, den ich für WebSockets/longpolling nutze. Leider hab ich da noch keinen Weg gefunden, wie ich den sinnvoll umgehen kann... ich muss mich mal näher damit beschäftigen, den schneller zu kriegen.
LG,
CK
Hallo MudGuard,
Und von anderen habe ich auch keine Beschwerden diesbezüglich gehört, wie gesagt, ich habe extra nachgefragt nach deinem Posting.
Was bei mir immer (oder fast immer, ich achte nicht immer darauf) der Fall ist: nachdem die Seite geladen ist, steht noch ewig lange "Waiting for node.forum.selfhtml.org..." in der Statuszeile meines Firefox.
ich hab jetzt mal ein Update des Nginx gemacht. Der kann jetzt tatsächlich WebSockets und muss nicht mehr longpolling machen (nur noch als Fallback), damit sollte sich die Sache deutlich beschleunigen.
LG,
CK
Hi,
nachdem die Seite geladen ist, steht noch ewig lange "Waiting for node.forum.selfhtml.org..." in der Statuszeile meines Firefox.
ich hab jetzt mal ein Update des Nginx gemacht. Der kann jetzt tatsächlich WebSockets und muss nicht mehr longpolling machen (nur noch als Fallback), damit sollte sich die Sache deutlich beschleunigen.
Ich kann bestätigen: das node-dingens ist nicht mehr im Statusbar nach Laden der Seite!
cu,
Andreas a/k/a MudGuard
Hallo,
vorweg: ich hatte völlig vergessen minifying zu aktivieren. Das habe ich jetzt nachgeholt, dadurch ist die Dateigrösse auf 500kb runter. Dazu habe ich GZip compression wieder aktiviert, damit bin ich auf ca 150kb runter.
das ist schon mal gut, denn seit ein paar Minuten habe ich auch den Eindruck, dass es deutlich flotter geht (nur noch wenige Sekunden). Und die übertragene Datenmenge pro Seitenabruf ist laut Opera nur noch so um 200kB.
Verwirrend, denn ich bin mir sicher, dass ich mit 900kb auch über längere Zeit ziehen kann (ich hole mir gelegentlich einen Datenbank-Dump, um aktuelle Test-Daten zu haben).
Ja, wenn mein Linux z.B. Updates zieht, geht das auch mit 700..750kB/s stabil.
Hat dein Opera vielleicht eine Obergrenze für Cache-Entries und er cached sie deshalb nicht?
Nicht erkennbar, und die Cache-Größe insgesamt ist mit 400MB (Disk) IMO schon reichlich bemessen. Ich hatte mal ein Cache-Problem mit Opera, als ich eingestellt hatte, er solle nur RAM für den Cache verwenden. Das hat sich in Wohlgefallen aufgelöst, als ich ihm erlaubt habe, auch auf Disk zu cachen.
Dein Vorschlag ist übrigens trotzdem intererssant, aber wenn, dann müsste es ja eher von der Größe der Ressource abhängen, ob Opera sie cachen möchte. Hmm, Moment mal ... [opera:config#cache]
Wow. Da sind getrennte Einstellmöglichkeiten für "Document Cache" (Default: 2000kB), "Image Cache" (Default: 2000kB) und "SVG Cache" (Default: 40960kB). Die per GUI eingestellten 400MB tauchen hier nirgends auf. Sehr seltsam. Ich setz den Document Cache mal deutlich hoch, sagen wir, aufs Zehnfache. Mal sehen, ob sich was ändert.
So long,
Martin
Hallo Martin,
vorweg: ich hatte völlig vergessen minifying zu aktivieren. Das habe ich jetzt nachgeholt, dadurch ist die Dateigrösse auf 500kb runter. Dazu habe ich GZip compression wieder aktiviert, damit bin ich auf ca 150kb runter.
das ist schon mal gut, denn seit ein paar Minuten habe ich auch den Eindruck, dass es deutlich flotter geht (nur noch wenige Sekunden). Und die übertragene Datenmenge pro Seitenabruf ist laut Opera nur noch so um 200kB.
Wenige Sekunden ist viel zu viel, ich bin bei mir auf 200ms runter für die Hauptseite.
Dein Vorschlag ist übrigens trotzdem intererssant, aber wenn, dann müsste es ja eher von der Größe der Ressource abhängen, ob Opera sie cachen möchte. Hmm, Moment mal ... [opera:config#cache]
Das war auch gemeint, als ich von "Cache-Entries" schrieb :-)
Wow. Da sind getrennte Einstellmöglichkeiten für "Document Cache" (Default: 2000kB), "Image Cache" (Default: 2000kB) und "SVG Cache" (Default: 40960kB). Die per GUI eingestellten 400MB tauchen hier nirgends auf.
Vermutlich bezieht sich das auf die insgesamte Cache-Grösse, also alles zusammen.
Sehr seltsam. Ich setz den Document Cache mal deutlich hoch, sagen wir, aufs Zehnfache. Mal sehen, ob sich was ändert.
Ich bin gespannt.
LG,
CK
Hallo,
das ist schon mal gut, denn seit ein paar Minuten habe ich auch den Eindruck, dass es deutlich flotter geht (nur noch wenige Sekunden). Und die übertragene Datenmenge pro Seitenabruf ist laut Opera nur noch so um 200kB.
Wenige Sekunden ist viel zu viel, ich bin bei mir auf 200ms runter für die Hauptseite.
pah, von sowas kann ich träumen. Ungefähr 300 bis 500ms ist allein schon die übliche Verzögerung zwischen HTTP-Request und zugehöriger Response. Antwortzeiten von ein bis zwei Sekunden vom Klicken bis zum Anzeigen einer Webseite sind für mich völlig normale Werte.
Sehr seltsam. Ich setz den Document Cache mal deutlich hoch, sagen wir, aufs Zehnfache. Mal sehen, ob sich was ändert.
Ich bin gespannt.
Ich auch. Ich sehe aber gerade im Protokoll der Fritzbüx, dass seit etwa 14 Uhr einige Male die Internet-Verbindung getrennt und wieder hergestellt wurde, zuletzt um 15.32 Uhr. Da ist oder war also auch etwas faul.
Ich beobachte das mal und halte mich mit weiteren "Meckereien" ein Weilchen zurück.
So long,
Martin
Hallo Martin,
das ist schon mal gut, denn seit ein paar Minuten habe ich auch den Eindruck, dass es deutlich flotter geht (nur noch wenige Sekunden). Und die übertragene Datenmenge pro Seitenabruf ist laut Opera nur noch so um 200kB.
Wenige Sekunden ist viel zu viel, ich bin bei mir auf 200ms runter für die Hauptseite.
pah, von sowas kann ich träumen. Ungefähr 300 bis 500ms ist allein schon die übliche Verzögerung zwischen HTTP-Request und zugehöriger Response. Antwortzeiten von ein bis zwei Sekunden vom Klicken bis zum Anzeigen einer Webseite sind für mich völlig normale Werte.
Huch, nur hier im Forum oder allgemein? Woran liegt das? Das würde mich wahnsinnig machen.
LG,
CK
Hi,
Ungefähr 300 bis 500ms ist allein schon die übliche Verzögerung zwischen HTTP-Request und zugehöriger Response. Antwortzeiten von ein bis zwei Sekunden vom Klicken bis zum Anzeigen einer Webseite sind für mich völlig normale Werte.
Huch, nur hier im Forum oder allgemein? Woran liegt das? Das würde mich wahnsinnig machen.
nein, generell. Ich hab's noch nie besser kennengelernt.
Die Ping-Antwortzeiten sind zwar gut, meist so um 50..60ms, heute aber auch deutlich daneben mit über 100ms. Was ist denn los, potzblitz?
Ciao,
Martin
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
pah, von sowas kann ich träumen. Ungefähr 300 bis 500ms ist allein schon die übliche Verzögerung zwischen HTTP-Request und zugehöriger Response. Antwortzeiten von ein bis zwei Sekunden vom Klicken bis zum Anzeigen einer Webseite sind für mich völlig normale Werte.
Hast Du schon mal nachgeschaut, wie das TTL deines zuständigen Nameservers eingestellt ist? Wenn das zu klein ist, warum auch immer, muss die Namensauflösung bei jedem Request wiederholt werden. Das hatte ich hier mal, als ich an Arcor hing.
Spirituelle Grüße
Euer Robert
robert.r@online.de
Hi,
Hast Du schon mal nachgeschaut, wie das TTL deines zuständigen Nameservers eingestellt ist?
bei meinem lokalen DNS auf 24h. Was mein Internet-Zugangsprovider 1&1 da anstellt, weiß ich nicht. Ich wüsste auch nicht, wie ich das rausfinde.
Wenn das zu klein ist, warum auch immer, muss die Namensauflösung bei jedem Request wiederholt werden. Das hatte ich hier mal, als ich an Arcor hing.
Klingt logisch.
So long,
Martin
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
Hast Du schon mal nachgeschaut, wie das TTL deines zuständigen Nameservers eingestellt ist?
bei meinem lokalen DNS auf 24h. Was mein Internet-Zugangsprovider 1&1 da anstellt, weiß ich nicht. Ich wüsste auch nicht, wie ich das rausfinde.
Wenn das zu klein ist, warum auch immer, muss die Namensauflösung bei jedem Request wiederholt werden. Das hatte ich hier mal, als ich an Arcor hing.
Klingt logisch.
Guckst Du einfach hiermit Heise Web Tools
Damit bekommst Du zumindest schon mal das original TTL des Zonen-DNS
Wie man an das TTL des Spiegels beim I-Access-Providers rankommt, weiß ich jetzt auch nicht. Aber das lässt sich bestimmt auch herausbekommen ;-) Ich lese mal weiter...
Spirituelle Grüße
Euer Robert
robert.r@online.de
Guten Abend,
Antwortzeiten von ein bis zwei Sekunden vom Klicken bis zum Anzeigen einer Webseite sind für mich völlig normale Werte.
und ungefähr auf dem Niveau läuft's jetzt wieder. Okay, für datenintensive Seiten wie die gesamte Thread-Liste vielleicht auch mal vier, fünf Sekunden. Aber da habe ich ja schon eingeräumt, dass ich den serverseitigen Aufwand respektiere und ein paar Sekunden Wartezeit "ohne Mullen und Knullen" akzeptiere.
Ich auch. Ich sehe aber gerade im Protokoll der Fritzbüx, dass seit etwa 14 Uhr einige Male die Internet-Verbindung getrennt und wieder hergestellt wurde, zuletzt um 15.32 Uhr. Da ist oder war also auch etwas faul.
Ich beobachte das mal und halte mich mit weiteren "Meckereien" ein Weilchen zurück.
Mittlerweile hat sich hier die Lage wieder normalisiert. Ganz offensichtlich hat mein Internet-Provider 1&1 übers Wochenende ein Problem gehabt. Die schon erwähnten sporadischen Trennungen der Internet-Verbindung waren ein Symptom, aber auch in den Intervallen dazwischen hatte ich an einem 6Mit-DSL-Anschluss nur noch Transferraten von maximal etwa 50kB/s, die meiste Zeit sogar noch weniger.
Am Samstagabend war's so extrem, dass durch die geringe verfügbare Bandbreite sogar die VoIP-Telefonie gelitten hat: Ich konnte meinen Gesprächspartner teilweise nur mit Mühe verstehen, und andersrum war es vermutlich genauso.
Gestern abend habe ich die Hotline des Providers deswegen angefixt, die schienen nichts zu wissen, haben das aber mal als Störungsmeldung aufgenommen. Als ich heute am späten Nachmittag nach Hause kam, lief aus unerfindlichen Gründen wieder alles wie geschmiert.
Immerhin hat meine Meckerei hier dazu geführt, dass eine bis dato unkomprimierte über 1MB große Ressource nun gzip-komprimiert ausgeliefert wird. Das ist ja auch schon was wert. Und dass ich bei der Gelegenheit einen genaueren Blick auf Operas Cache-Einstellungen geworfen habe, war sicher auch nicht falsch.
Sorry für den großen Aufstand, den ich verursacht habe - die Ursache lag tatsächlich hier, aber nicht direkt bei mir. ;-)
Ciao,
Martin
Hallo Martin,
Antwortzeiten von ein bis zwei Sekunden vom Klicken bis zum Anzeigen einer Webseite sind für mich völlig normale Werte.
und ungefähr auf dem Niveau läuft's jetzt wieder.
Ich finde es immer noch faszinierend, dass du mit so einem Internet unterwegs bist. Das würde mich wirklich wahnsinnig machen, und dabei wohnst du doch in der Stadt?
Okay, für datenintensive Seiten wie die gesamte Thread-Liste vielleicht auch mal vier, fünf Sekunden.
Ja, da kann ich leider wirklich nicht so viel machen. Ich verzichte aus Performance-Gründen schon auf ein Partial zum rendern der Thread-Liste und verwende eine Funktion für die Message-Header statt eines Templates.
Immerhin hat meine Meckerei hier dazu geführt, dass eine bis dato unkomprimierte über 1MB große Ressource nun gzip-komprimiert ausgeliefert wird. Das ist ja auch schon was wert.
Ja. Das kommt davon, dass man Sachen auf später verschiebt und sie nicht aufschreibt. Ich werd halt auch nicht jünger ;-)
LG,
CK
Hallo Martin,
GET /assets/application-435e2eab22e5fc9b9cbc7633efb70856ed7c9059c05d017169d52b1d2b61f563.js HTTP/1.1 Host: forum.selfhtml.org [...] Accept: */* Accept-Language: en-us,en;q=0.7,de;q=0.3 Accept-Encoding: gzip, deflate Referer: http://forum.selfhtml.org/ [...] Connection: keep-alive HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Fri, 08 May 2015 11:20:55 GMT Content-Type: application/x-javascript Content-Length: 1112156 Connection: keep-alive Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000, public Accept-Ranges: bytes
Hm, da fehlt bei dir ein Last-Modified-Header. Browser haben manchmal Probleme mit dem cachen, wenn der nicht vorhanden ist. Sicher, dass der nicht da ist? Bei mir ist er nämlich:
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Fri, 08 May 2015 14:03:14 GMT
Content-Type: application/javascript
Content-Length: 523845
Last-Modified: Wed, 06 May 2015 12:06:38 GMT
Connection: keep-alive
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Cache-Control: public
Accept-Ranges: bytes
Warum?
If-Modified-Since kann nur mit Last-Modified gemacht werden. Hast du irgend einen Proxy dazwischen, der das rausfiltert?
LG,
CK
Hi,
Hm, da fehlt bei dir ein
Last-Modified-Header. Browser haben manchmal Probleme mit dem cachen, wenn der nicht vorhanden ist. Sicher, dass der nicht da ist? Bei mir ist er nämlich:
guter Punkt, aber wenn er da war, dann hat Firefox bzw. dessen LiveHTTP-Extension den unterschlagen.
If-Modified-Sincekann nur mitLast-Modifiedgemacht werden. Hast du irgend einen Proxy dazwischen, der das rausfiltert?
Nicht wissentlich. :-/
Aber Operas Dragonfly verrät mir, dass die Monster-Script-Ressource inzwischen doch gecacht wird und der pro-forma-Request nach 514ms mit Status 304 beantwortet wird. So gefällt mir das.
Scheint das Drehen an den Cache-Einstellungen ja doch geholfen zu haben.
Ciao,
Martin
Hallo Martin,
guter Punkt, aber wenn er da war, dann hat Firefox bzw. dessen LiveHTTP-Extension den unterschlagen.
Guck doch bitte mal in den Network-Tab der Dev-Tools. Die sind wohl genauer als LiveHTTP ;-)
Aber Operas Dragonfly verrät mir, dass die Monster-Script-Ressource inzwischen doch gecacht wird und der pro-forma-Request nach 514ms mit Status 304 beantwortet wird. So gefällt mir das.
Nach 514ms?! Was hast du für ein Internet? Das geht ja selbst hier auf dem platten Land schneller ;-)
LG,
CK
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
ich habe das dumpfe Gefühl, es besteht immer noch erheblicher Optimierungsbedarf bei der Forensoftware bzw. deren Web-Schnittstelle.
Mir fällt immer wieder unangenehm auf, dass selbst das Laden der Forenübersicht http://forum.selfhtml.org/ ziemlich lange dauert (andere Seiten natürlich auch). Mein Opera, der in der Fortschrittsanzeige beim Laden sowohl die verstrichene Zeit, als auch die übertragene Datenmenge live mitzählt, kommt für die genannte Übersichtsseite regelmäßig auf über 30, manchmal sogar über 40 Sekunden und rund 1.2MB.
Das beobachte(t)e ich auch schon eine ganze Weile. Auf dem Desktop stört mich das nicht weiter, weil man trotzdem schon anfangen kann, die oberen Threads zu lesen, wenn der Browser noch (bis zu ca. 30") weiterlädt.
Auf dem Tablet hat das aber die unangenehme Nebenerscheinung, das erst der Teil der Seite unter dem Strich geladen wird und wenn man dann schon denkt, man könne einen Betrag auswählen, springt das Bild plötzlich hin und her, weil dann der obere Teil geladen wird/wurde...
Spirituelle Grüße
Euer Robert
robert.r@online.de