Hallo,
vielleicht kennt ihr die Webseite, auf der die aktiven Server der exit
notes des Tor-Projekts aufgelistet sind:
https://torstatus.blutmagie.de
Rufe ich diese Seite mit dem Firefox auf, so friert dieser für gut 30s
teilweise ein. Sprich den Großteil der Zeit lässt sich Firefox nur sehr
träge bedienen oder blockiert völlig.
NoScript verbietet jeglichen Javascriptcode für diese Seite, sollte also
reines HTML sein. Nach den 30s ist die Serverliste geladen und Firefox
funktioniert wider normal. Speichert man die geladene Webseite ab, so
hat die HTML-Datei etwa 12MByte ob der langen Liste.
Kennt jemand von Euch ein ähnliches Problem? Kann es sein, dass Firefox
tatsächlich so lange zum parsen des HTML-Codes braucht, weil der
Download der 12MByte dauert keinesfalls so lange. CPU Auslastung liegt
bei etwa 12% in der Hängephase bei einem 4(8)-Kern Prozessor. RAM ist
ausreichend vorhanden.
Besten Dank im Voraus,
Roland.
Interessant, hängt dort auch der ganze Bowser?
Also das der Tab hängt oder eben der Ladekreis sich dreht, das kennt man
ja. Aber das gleich der ganze Browser wegen einer Seite hängt ist schon
ungewöhnlich irgendwie, zumal jetzt auch kein Plugin àla Flash
abschmiert.
Ja, alles hängt wie in deiner Beschreibung, wobei Opera 12.17 ja auch
schon etwas älter ist. Dieses Phänomen sehe ich ab und zu, dh. ich habe
es etwa 5 Mal bisher bei ein paar Seiten beobachten können.
Firefox hatte zumindest ewige Zeit nur einen Prozess für die gesamte
Anzeige. Ob das noch so ist, weiß ich nicht, aber die Tatsache, dass die
oben genannte Seite Firefox nicht mehr reagieren lässt und ein CPU-Kern
auf 100% hängt, spricht dafür.
Opera 33 (also Chrome (=> 1 Prozess pro Tab) mit anderem Logo und ein
paar anderen Detailänderungen) lädt die Seite viel schneller und bleibt
währenddessen bedienbar.
Also ich kenne dieses Hängenbleiben vorallen von Javascripts. Wenn ein
Script lange rechnet oder gar hängt, dann hängt der komplette Firefox
und nach einer Weile kommt das Popup mit der Meldung das ein Script
nicht antwortet.
Beim Internet Explorer hingegen hängt bei rechenintensiven Scripts nur
der zuständige Tab, da hier wohl auch mehrere Prozesse erstellt werden.
Was mich jedoch so wundert, dass Firefox bei reinem HTML auch hängt.
Braucht das Darstellen einer 12MByte großen HTML Datei wirklich so
lange?
Roland schrieb:> Was mich jedoch so wundert, dass Firefox bei reinem HTML auch hängt.> Braucht das Darstellen einer 12MByte großen HTML Datei wirklich so> lange?
...ähm, ja, wenn dem Browser nicht durch entsprechende Anweisungen in
den Metadaten, beim Rendern der Ausgabe "geholfen" wird bzw. der
HTML-Code insgesamt durch HTML-Regelverstösse (beliebt sind z.B.
fehlende """) strotzt. Bei 12MByte dürften sich solche Probleme dann
schon summieren, die bei "normalen" Seiten nur ein paar 10tel Sekunden
ausmachen.
Ja ich kann das Problem auch nachvollziehen. Bei mir friert es zwar
nicht dauerhaft ein, aber Firefox hängt so sehr, dass es kaum noch zu
bedienen ist.
CPU Auslastung ist bei 100%.
FF 42.0 unter Linux Mint 17.2
Vielen Dank für die Antworten, scheint also wirklich so zu sein, dass
der Bowser zum parsen der HTML-Anweisungen und zum Formatieren der
CSS-Vorlage derart lange braucht. Unabhängig vom Betriessystem und
CPU-Rechnenleistung.
Dauert wohl noch ein paar Firefoxrevisionen bis jeder Tab einen eigenen
CPU-Prozess bekommt um das Blockieren des gesamten Browsers in solch
einem Fall zu verhindern ;-).
Ein Kern fast 100% Auslastung, flüssiges Scrollen auf der Seite während
des ladens problemlos möglich und keine Auwirkungen auf andere Tabs.
FF 3.0.19
FF sollte wohl mal wieder zu den Wurzeln zurück statt sich weiter sinn-
und verstandlos aufzublasen. :-D
Die Seite ist recht lang, so das mein SeaMonkey 2.39/XP ein wenig
braucht. Lädt aber komplett und ich kann währenddessen im anderen Tab
weiter durchs MC.net scrollen.
Der Apache 2.2 Server bei denen scheint aber auch nicht der schnellste
zu sein.
aha schrieb:> Ein Kern fast 100% Auslastung, flüssiges Scrollen auf der Seite> während> des ladens problemlos möglich und keine Auwirkungen auf andere Tabs.>> FF 3.0.19>> FF sollte wohl mal wieder zu den Wurzeln zurück statt sich weiter sinn-> und verstandlos aufzublasen. :-D
Lustig, in Version 3 blockiert nicht mal diese Seite wenn sie geladen
wird und in Version 44 der ganze Browser. In der Tat, back to roots wäre
angesagt, weil HTML parsen ist wohl das Grundlegendste.
Matthias S. schrieb:> Die Seite ist recht lang, so das mein SeaMonkey 2.39/XP ein wenig> braucht. Lädt aber komplett und ich kann währenddessen im anderen Tab> weiter durchs MC.net scrollen.
Interessant, obwohl SeaMonkey auf Firefox beruht funktioniert er besser.
Wenn ich die Seite mit Firefox 44.02 für Mac öffne, kommt nach einiger
Zeit diese Meldung:
Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet
nicht mehr. Sie können das Skript jetzt stoppen, im Debugger öffnen oder
weiter ausführen.
Skript: chrome://global/content/bindings/browser.xml:333
Und außerdem war mein Firefox noch 'ne ganze Weile mit sich selbst
beschäftigt und hat gestottert und gezickt, nachem ich die Seite bzw.
den Tab längst geschlossen hatte.
Das ist die Krankheit von 64-Bit-FF, die mir schon lange ziemlich auf
den Geist geht. Das Problem wird immer schlimmer, je mehr Fenster offen
sind und je mehr Tabs und je länger er schon läuft. Ich habe ihn hier
nach 5 Minuten Laden von https://torstatus.blutmagie.de/ abgeschossen.
Er hatte es gerade mal geschafft, die Icons auf die Tabs zu malen, der
Rest war weiß und FF hat auf nichts, außer kill -9 reagiert.
JS war auch abgeschaltet.
Das Problem ist wohl ein nicht mehr ganz neues
Speicherverwaltungsproblem der 64-Bit-Version, den die Schnapsnasen
einfach nicht beheben.
Chromium zeigt den Anfang der Seite sofort an, lädt dann aber noch ein
paar Sekunden weiter, bis er alles beisammen hat.
Roland schrieb:> Interessant, obwohl SeaMonkey auf Firefox beruht funktioniert er besser.
Die SeaMonkey Leute haben schon vor einiger Zeit angekündigt, nicht mehr
jeden Mist mitzumachen, den FF vormacht.
Mal den Seitenquelletext angeschaut?
Da hat einer versucht XHTML zu schreiben, es aber nicht verstanden und
zum Glück auch nicht hingekriegt.
Sonst würde der Firefox nur eine reine Fehlermeldungs-Seite anzeigen,
und garkeinen Content.
Aber die Seite kommt dann wenigstens schnell :)
Die Seite will diverse Grafiken nachladen, was je Grafik zwischen 0,5s
und 2s dauert. Bei 110 Anfragen in Summe steht der Browser... das ist
eher Inkompetenz seitens des Seitenbetreibers wie ich finde.
Nachprüfbar im FF über Extras -> Web-Entwickler -> Laufzeitanalyse und
weitere...
Uhu U. schrieb:> Das ist die Krankheit von 64-Bit-FF, die mir schon lange ziemlich auf> den Geist geht. Das Problem wird immer schlimmer, je mehr Fenster offen> sind und je mehr Tabs und je länger er schon läuft.
Das ist bei der 32-Bit-Version genauso.
In den letzten Jahren war jede neuere Version schlechter als die ältere
und diesen Schice kriegt man immer häufiger aufgedrängt.
Aber das ist wohl der aktuelle Zeitgeist. Wahrscheinlich pfuscht da
jetzt eine Programmierergeneration, die es einfach nicht mehr kapiert,
was wirklich wichtig ist.
Grüße
Richard
hab das Problem mit Firefox andauernd...zwischendurch ist einfach Pause
und nix geht mehr. Eigentlich wirds Zeit, Firefox in die Tonne zu
kloppen.
Das ist ein aufgeblähter Haufen Mist!
beim ersten Aufruf der Seite über den Link hat sich mein FF Version
38.6.1 gleich mal mit einem Absturz voll verabschiedet, es waren wohl
parallel zu "viele" FF-Seiten schon offen , ca. 25 !
jetzt bei fast keinen offenen Seiten braucht der Aufbau der Seite über
10 sec. und hat dann über 300 MB im RAM dafür belegt,
und was ist auf der Seite bitte so Systemlastig? die paar kleinen
Grafiken links für die Länderfähnchen?
da trifft sich wohl eine schlampig programmierte Seite mit einer ebenso
stümperhaft gewordenen Anwendung - fast aktueller Firefox.
Mit dem IE V8 ist es noch schlimmer, über 650 MB und fast volle
CPU-Last, aber die Seite ist gleich im oberen Bereich wenigstens
sichtbar, wenn auch lange nicht bedienbar.
Niemand schrieb:> beim ersten Aufruf der Seite über den Link hat sich mein FF Version> 38.6.1 gleich mal mit einem Absturz voll verabschiedet, es waren wohl> parallel zu "viele" FF-Seiten schon offen , ca. 25 !
Schau mal, was unter Einstellungen/Erweitert/Netzwerk unter Cache
eingestellt ist.
Wenn der überläuft, kann der FF oder gar W7 abstürzen.
Ich habe den manuell auf 512MB und leere den regelmäßig.
Falls ich das doch mal verpasse, dann kackt auch schon mal das W7 ab.
Für WIN ist jetzt V.44 aktuell??
michael_ schrieb:> Ich habe den manuell auf 512MB und leere den regelmäßig.
Lass das doch Firefox machen.
Einstellungen → Datenschutz → "Chronik löschen, wenn Firefox
geschlossen" anklicken → danach rechts auf Einstellungen und nur Cache
auswählen
