Erg traag onder Mozilla

[MahRain]

Als ik met mozilla op het forum ga, is het de laatste tijd onmogelijk traag. Met internet explorer 6 heb ik nergens last van. Hij laad over deze pagina met mozilla 80 seconden, met IE staat het gewoon na een paar secondes op het scherm.

Hij is lang bezig gathering.tweakers.net.... te laten en images.tweakers.net (ook nu hij done zegt missen er een 6 tal smileys)

Waar ligt dit aan?

Ik heb zowel compressie (in m'n prefs) als pipelining (in de browser zelf) aanstaan en in beide browsers ben ik ingelogd.

[WouterG]

Ik heb juist met internet explorer 6.0 de laatste tijd erg lange wachttijden. Het duurt gewoon lang voordat hij begint. De pagina zelf word wel snel opgebouwt. Andere sites hebben dit probleem niet. Ik zou niet weten waardoor dat zou kunnen?

[Osiris]

Javascript aan/uit?

[RooT]

Nergens last van hier.
Met mozilla 1.0 heb ik: Total: 0,114 | Incl: 0,038, Init: 0,032, Action: 0,049 | DB: 0,021, Tpl: 0,033.
Met IE 6: Total: 0.101 | Incl: 0.017, Init: 0.041, Action: 0.049 | DB: 0.034, Tpl: 0.017 .

Dus onder mozilla of IE, werkt allebei evengoed hier. Lijkt me dus sterk dat het aan mozilla zou liggen, misschien verkeerde instellingen ?

[Chaos]

Heb ik hier inderdaad ook met Mozilla 1.1b onder windows 2000. Geen oplossing voor kunnen vinden.

RooT: natuurlijk zijn die tijden hetzelfde, de server wordt niet ineens langzamer als er een Mozilla aan de andere kant van de lijn zit.

[vandenberg]

Chaos schreef op 07 augustus 2002 @ 23:26:
Heb ik hier inderdaad ook met Mozilla 1.1b onder windows 2000. Geen oplossing voor kunnen vinden.
...

Zelfde hier, terwijl het met IE6 echt rap gaat.

[RooT]

Chaos schreef op 07 augustus 2002 @ 23:26:
Heb ik hier inderdaad ook met Mozilla 1.1b onder windows 2000. Geen oplossing voor kunnen vinden.

RooT: natuurlijk zijn die tijden hetzelfde, de server wordt niet ineens langzamer als er een Mozilla aan de andere kant van de lijn zit.

Die tijden zijn toch de tijd dat de pagina inlaad
Of heb ik 't nu fout?

[Chaos]

De tijd die de server nodig heeft om de pagina te bouwen. Ik heb net trouwens 1.1a weer van stal gehaald, maar die doet het ook. Straks 1.0 nog maar eens proberen.

[Wokschotel]

Chaos schreef op 08 augustus 2002 @ 09:27:
De tijd die de server nodig heeft om de pagina te bouwen. Ik heb net trouwens 1.1a weer van stal gehaald, maar die doet het ook. Straks 1.0 nog maar eens proberen.

De tijden die de server ervoor nodig heeft staan onderaan de pagina. Vergelijk die eens als je met IE en Mozilla pagina's opent?

[Bosmonster]

Wokschotel schreef op 08 augustus 2002 @ 09:32:
[...]De tijden die de server ervoor nodig heeft staan onderaan de pagina. Vergelijk die eens als je met IE en Mozilla pagina's opent?

Ze staan wit op wit, dus sleep ff met je muis onder de logo's

[Bosmonster]

Trouwens even geprobeerd op Mozilla 1.1a die ik hier had. En het is snel, zo niet sneller dan in IE6 die ik normaliter gebruik.

[Chaos]

De tijden die de server ervoor nodig heeft staan onderaan de pagina. Vergelijk die eens als je met IE en Mozilla pagina's opent?

Jij denkt dat Microsoft ze betaalt om opzettelijk vertragingen in te bouwen als er een Mozilla langskomt? Komop zeg, het is hotmail niet.

En 1.0.0 doet het ook.

[ Voor 0% gewijzigd door Chaos op 08-08-2002 10:13 . Reden: typo ]

[Chaos]

Bosmonster schreef op 08 augustus 2002 @ 09:55:
Trouwens even geprobeerd op Mozilla 1.1a die ik hier had. En het is snel, zo niet sneller dan in IE6 die ik normaliter gebruik.

Welke windows gebruik jij? XP? Ik heb eens wat rondgevraagd en het lijkt erop dat het de combinatie Mozilla/win2k is die problemen geeft.

[ACM]

Mijn mozilla (onder XP) doet ook wel sloom, met IE ging react (en topix ook) altijd al (ietsje) sneller, heb verder niet echt getest of het browsen er veel sneller mee is of niet.

[Crazy D]

De tijden onderaan de pagina zijn zowel bij IE als Mozilla zo'n beetje gelijk, maar ook bij mij is gotten met mozilla een hell (WinXP, Mozilla build van 3 dagen terug). Deze pagina deed er nu toevallig maar 9 seconde over (Document: Done (9.844 sec)), maar ik heb ze ook gehad dat het rustig 40 seconden duurt, terwijl in IE de pagina er direct staat (mijn inet verbinding is het probleem niet).
Het maakt ook niet uit of ik compressie aan of uit zet, ook niet of ik wel of geen javascript gebruik voor de lijsten. Het enigste wat ik kan verzinnen is dat de html nogal brak is (wat ie is, gooi bv deze pagina maar eens door validator.w3.org). Het is iig erg storend en behoorlijk vreemd, t.net is wel snel en ook met andere pagina's heb ik er geen enkel probleem mee. Alleen GoT is baggertraag

PS hmmph kwou dus nog ff zeggen dat met topix ik nergens last van had, en met het test huischkamertje eigenlijk ook niet. Tis denk ik zo'n beetje begonnen iets voor dat images.t.net er de brui aan had gegeven (en in die dagen was 300 seconden voor een pagina ook niks ), tis nu wel weer sneller dan toen (scheelde ook dat ik icq icoontjes ff uit heb gezet), maar dit blijft huilen. Tussen het moment van op de edit icoon klikken en dat ik de tekst kon gaan typen, heb ik al op mn gemakje een shaggie gedraait. En nu heeft ie toch weer moeite met images.t.net. Document: Done (184.61 secs). Cache uiteraard al leeggegooid maar dat maakt natuurlijk niets uit

[flat]

ik dacht dat de traagheid van 't forum dus kwam omdat nog niet alles goed geconfigured was (waar vorige week sprake van was), maar met IE is alles dus wel snel

nog even wat info (kan misschien van pas komen bij 't vaststellen van 't probleem):
win2k, mozilla 2002080119 (zal 'm straks eens updaten),
pipelining maakt niets uit, en de dingen die ik in de prefs kan instellen ook niet
de tijd om de pagina op de server te maken is gewoon laag: Total: 0,087
maar als ik 'n GoT-pagina op mijn eigen server wget, en die vervolgens open in mozilla, gaat 't wel goed

misschien dat mozillade dingen van images.tweakers.net niet cached ofzo?

[chem]

moz 1.1b onder OS X doet deze page in 1.8 sec, en chimera in een "oogwenk"...

[flat]

hmmm slim idee om dat ook even te testen chem

met mfcembed werkt 't hier ook supersnel, ietsje sneller dan IE zelfs

[ACM]

Ik heb nu de nightly van vannacht gedownload en die lijkt sneller.

Ik zou het op prijs stellen als meerdere mensen die downloaden en even bekijken of het daarmee allemaal wat soepeler loopt.

[flat]

2002080718 is inderdaad sneller, maar 't gaat toch nog zeker dubbel zo snel als je mcfembed gebruikt...

[ACM]

Ja, ik had ook goede hoop, maar toen duurde een page ineens weer 5+ seconden
Al met al ben ik wel sterk geneigd om dit alles op 'bugs' van Mozilla te gooien, als iemand met een briljante oplossing komt houden we ons natuurlijk van harte aanbevolen, maar ik denk niet dat ik actief op zoek ga naar een oorzaak zolang mozilla 1.1 niet uit is (en er ook last van blijkt te hebben).

[flat]

ik heb nu pipelining uitgezet, en 'm zo ingesteld dat 'ie maar eens per session checked of de cache nog up-to-date is
en nu werkt 't echt wel snel

alleen is 2002080718 nogal buggy wat betreft tabs en refreshen lijkt 't
zo kan kan ik de tabs die ik open op geen enkele mogelijkheid meer sluiten

[ACM]

Flat© schreef op 08 augustus 2002 @ 11:15:
alleen is 2002080718 nogal buggy wat betreft tabs en refreshen lijkt 't
zo kan kan ik de tabs die ik open op geen enkele mogelijkheid meer sluiten

Hey, inderdaad

Magoed, jouw settings zijn hier ook niet sneller

[flat]

da's vaag
want hier is dat echt 'n wereld van verschil...
en keep-alive staat wel aan?
edit: nog even getest, en pipelining maakt ook niet veel uit, maar dat van die cache dus wel

edit2: mijn verklaring:
met de default-settings, gaat 'ie bij elke refresh kijken of alle statische zooi nog actueel is, en aangezien images.tweakers.net niet echt snel is
dus als je die op eens per sessie zet, is dat verholpen, en gaat 't lekker snel (zelfs sneller dan IE lijkt 't )

[Chaos]

Cache nog maar een keer per sessie controleren lost hier inderdaad ook het probleem op^*. Wat mij opvalt is dat de timeout op images.tweakers.net belachelijk laag is, als Mozilla's manier van plaatjes opvragen ervoor zorgt dat thttpd tussendoor constant de verbinding dichtgooit zou dat wel verklaren dat het zo verschrikkelijk traag gaat.

* Nouja, oplossen... de eerste pagina duurt enorm lang en daarna gaat het goed.

[flat]

chaos: da's logisch hè, want dan checkt 'ie wel de cache

maar even half off-topic: is deze build van mozilla echt zo ongelofelijk brak?
links in nieuwe tabs openen werkt niet, tabs zijn niet te sluiten, en refreshen werkt ook voor geen meter

[ACM]

Mja, nu loopt het wel...
net of ie aanloop probleempjes had

Magoed, het is niet echt een oplossing dat je de checking van data op "per sessie" moet zetten, maar ik meen dat IE dat default wel doet en daar heb je dan een deel van het verschil...

[Chaos]

Flat: Weet ik, maar ik wilde dat even benadrukken om te voorkomen dat hier een slot op wordt geknald zonder dat er iets aan gedaan is.

[Verwijderd]

ACM schreef op 08 augustus 2002 @ 11:15:
Al met al ben ik wel sterk geneigd om dit alles op 'bugs' van Mozilla te gooien,

Vooral altijd de makkelijkste weg nemen..

als iemand met een briljante oplossing komt houden we ons natuurlijk van harte aanbevolen,

De braindead webserver die op images.tweakers.net draait snapt niet wat "Connection: keep-alive" betekent.

Even een ethereal logje (alleen relevante stukjes)

code:

Frame 1945
    Time relative to first packet: 23.029156000 seconds
    Destination: apollo.tweakers.net (213.239.154.15)
Transmission Control Protocol, Src Port: 53011 (53011), Dst Port: http (80), Seq: 1079045332, Ack: 0
    Flags: 0x0002 (SYN)


Frame 1946
    Time relative to first packet: 23.065181000 seconds
    Source: apollo.tweakers.net (213.239.154.15)
Transmission Control Protocol, Src Port: http (80), Dst Port: 53011 (53011), Seq: 1069607898, Ack: 1079045333
    Flags: 0x0012 (SYN, ACK)


Frame 1947
    Time relative to first packet: 23.065261000 seconds
    Destination: apollo.tweakers.net (213.239.154.15)
Transmission Control Protocol, Src Port: 53011 (53011), Dst Port: http (80), Seq: 1079045333, Ack: 1069607899
    Flags: 0x0010 (ACK)

Okee, verbinding maken lukt prima en snel.

code:

Frame 2026
    Time relative to first packet: 24.840358000 seconds
    Destination: apollo.tweakers.net (213.239.154.15)
Hypertext Transfer Protocol
    HEAD / HTTP/1.1\r\n
    Host: images.tweakers.net\r\n
    Connection: keep-alive\r\n
    \r\n


Frame 2034
    Time relative to first packet: 24.895529000 seconds
    Source: apollo.tweakers.net (213.239.154.15)
Transmission Control Protocol, Src Port: http (80), Dst Port: 53011 (53011), Seq: 1069607899, Ack: 1079045403
    Flags: 0x0010 (ACK)


Frame 2035
    Time relative to first packet: 24.899915000 seconds
    Source: apollo.tweakers.net (213.239.154.15)
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Server: thttpd/2.21b 23apr2001\r\n
    Content-Type: text/html; charset=iso-8859-1\r\n
    Date: Thu, 08 Aug 2002 11:11:31 GMT\r\n
    Last-Modified: Sat, 16 Mar 2002 15:19:08 GMT\r\n
    Accept-Ranges: bytes\r\n
    Content-Length: 8\r\n
    Connection: keep-alive\r\n
    \r\n

Respons komt ook lekker snel. Merk op dat de webserver keep-alive ok vindt, en de verbinding blijft dus open.

code:

Frame 2110
    Time relative to first packet: 26.319324000 seconds
    Destination: apollo.tweakers.net (213.239.154.15)
Hypertext Transfer Protocol
    HEAD / HTTP/1.1\r\n
    Host: images.tweakers.net\r\n
    Connection: keep-alive\r\n
    \r\n


Frame 2118
    Time relative to first packet: 26.429989000 seconds
    Source: apollo.tweakers.net (213.239.154.15)
Transmission Control Protocol, Src Port: http (80), Dst Port: 53011 (53011), Seq: 1069608143, Ack: 1079045473
    Flags: 0x0010 (ACK)

2 seconden later komt nog een request, en Apollo stuurt direct een ACK.

code:

Frame 2258
    Time relative to first packet: 29.903046000 seconds
    Source: apollo.tweakers.net (213.239.154.15)
Transmission Control Protocol, Src Port: http (80), Dst Port: 53011 (53011), Seq: 1069608143, Ack: 1079045473
    Flags: 0x0011 (FIN, ACK)

Poef. Apollo sluit, bijna 6 seconden het eerste request, de verbinding. Zonder wat voor reply dan ook gegeven te hebben op tweede request.

Dump die webserver. Of configureer 'm goed.

maar ik denk niet dat ik actief op zoek ga naar een oorzaak zolang mozilla 1.1 niet uit is (en er ook last van blijkt te hebben).

Hmm. Ik denk dat je zelf wel kunt invullen wat ik van zo'n instelling vind.

(note: ik had het probleem binnen een minuut gevonden)

[ Voor 0% gewijzigd door Verwijderd op 08-08-2002 13:36 . Reden: React snapt, net als Topix ooit, niet wat lege regels in [code] zijn >:( ]

[ACM]

Verwijderd schreef op 08 augustus 2002 @ 13:30:
Vooral altijd de makkelijkste weg nemen..

Yups.

De braindead webserver die op images.tweakers.net draait snapt niet wat "Connection: keep-alive" betekent.

Mooi, want ik had allang bedacht dat de 'nieuwe' httpd op images.tweakers.net weer door de 'oude' vervangen moest worden.
DAT moest sowieso, ik had alleen niet verwacht dat dat het enige belangrijkste punt blijkt te zijn.

Poef. Apollo sluit, bijna 6 seconden het eerste request, de verbinding. Zonder wat voor reply dan ook gegeven te hebben op tweede request.

Dump die webserver. Of configureer 'm goed.

Is trouwens atlas, maar das niet relevant voor je uitleg
De httpd is een voor keep-alive gepatched thttpd versie, maar die is dus blijkbaar niet _zo_ goed in keep-alive als zo'n patch zou moeten bewerkstelligen, zsm stappen we weer terug op boa (de gene die bij topix al altijd gebruikt werd).

Hmm. Ik denk dat je zelf wel kunt invullen wat ik van zo'n instelling vind.
(note: ik had het probleem binnen een minuut gevonden)

Maakt mij niks uit wat je daarvan vind, ik heb nog wel een paar andere taken op mijn lijst staan, behalve uitzoeken waarom mozilla niet goed werkt.

Dat het met een minuut te vinden is, kom je pas achter ZODRA je het gevonden hebt, niet op het moment dat je wilt gaan zoeken...

Maar, ondanks dat: Bedankt voor je uitleg en je moeite.

[Onno]

ACM schreef op 08 augustus 2002 @ 14:46:
[nohtml][...]
Mooi, want ik had allang bedacht dat de 'nieuwe' httpd op images.tweakers.net weer door de 'oude' vervangen moest worden.

Waarom loop je dan Mozilla de schuld te geven?

Is trouwens atlas, maar das niet relevant voor je uitleg

$ host images.tweakers.net
images.tweakers.net is an alias for apollo.tweakers.net.

Tijd om DNS te fixen dan.

Dat het met een minuut te vinden is, kom je pas achter ZODRA je het gevonden hebt

Inderdaad, dus zoek je gewoon eerst 3 minuten, en als dat niets oplevert kun je het nog altijd laten voor wat het is.

[Floor-is]

IE: Total: 0,133 | Incl: 0,025, Init: 0,027, Action: 0,091 | DB: 0,024, Tpl: 0,051 | SV: argus.webmagix

Mozilla: Total: 0,175 | Incl: 0,003, Init: 0,078, Action: 0,145 | DB: 0,036, Tpl: 0,049 | SV: atlas.webmagix.net

Ik heb dus geen troubles

[Onno]

Pssst Floris, er is al lang gezegd dat het niets met de tijd te maken heeft die React over een pagina doet.

[ACM]

Onno schreef op 08 augustus 2002 @ 14:53:
Waarom loop je dan Mozilla de schuld te geven?

Dat was niet zozeer de schuld van het 'het duurt lang', maar meer de schuld van het 'het duurt _erg_ lang'.

Boa wilde ik sowieso weer terug ipv thttpd, omdat het 'lang duurde'.

Tijd om DNS te fixen dan.

Dat komt min of meer door de loadbalancers
Het was wel apollo (tot voor kort), maar omdat we die geen web-hulp-taken meer wilden laten doen ging dat ip over naar de loadbalancers en dat simpele httpd-tje dat eerst op apollo draaide over naar atlas.
Dat maakt voor het ip etc verder niet uit

Het ip hoort officieel nog wel bij apollo, dus het zit allemaal nog een beetje door elkaar gedraaid.

[Floor-is]

Onno schreef op 08 augustus 2002 @ 15:02:
Pssst Floris, er is al lang gezegd dat het niets met de tijd te maken heeft die React over een pagina doet.

Hier wat andere info dan die misschien helpen kan:

Euhm DNS:
213.239.154.10
213.239.154.12
213.239.128.5
213.239.128.3

1e 2 -> T.net
2e 2 -> TrueServer DNS-doosjes

IE is versie 6.0.2600 oid
Mozilla -> Mozilla 1.1a

Nog meer weten?

[ Voor 0% gewijzigd door Floor-is op 08-08-2002 15:12 . Reden: Aanpasssinkje ]

[Onno]

Floris schreef op 08 augustus 2002 @ 15:08:
Psst ik heb niet zo op zitten letten

[...]

Nog meer weten?

Ja, waarom lees je de thread niet gewoon?

(schattig btw, die [nohtml] zut van React als je iemand met html-rechten quote..)

[ACM]

Floris schreef op 08 augustus 2002 @ 15:08:

Das allemaal niet zo relevant

Het probleem ligt, blijkbaar, aan het feit dat de server-software achter images.tweakers.net niet helemaal (*kuch*) netjes de httpd-standaard aanhoudt wat betreft het zgn 'keep-alive', voor elk plaatje wil mozilla standaard even vragen of ie veranderd is en als ie dan verwacht dat er keep-alive wordt "gesproken", maar dat dus niet goed gedaan wordt, gaat het mis.

Dan moet mozilla dus regelmatig opnieuw de verbinding openen (redelijk traag) en ook er steeds weer achter komen dat de verbinding zomaar dichtgekwakt is (wederom een trage bedoening).

Aangezien IE standaard niet "kijkt of iets veranderd is", maar dat 'per browser sessie doet' (toch?) gaat het daar wel goed mee en dus ook als je je mozilla settings daarnaar aanpast.

Onno schreef op 08 augustus 2002 @ 15:13:

Ja, waarom lees je de thread niet gewoon?

(schattig btw, die [nohtml] zut van React als je iemand met html-rechten quote..)

Mja, dat wordt er bijgeplaatst om ons te beschermen tegen het gedoe met de <'s etc

Voor de gewone gebruikers is het wel handig als dat weer uit de quote wordt gefilterd, die tag werkt toch niet bij je

[Floor-is]

Hmm ik begrijp uit de tekst van ACM dat het dus aan BOA ligt, of iig dat Mozilla een andere manier heeft om dingen te checken, waardoor het nogal traag kan gaan.
Dan moeten wij het dus aanpassen en een beetje vlot als het kan.

Onno: ik zal mijn leven beteren

[ACM]

Floris schreef op 08 augustus 2002 @ 15:26:
Hmm ik begrijp uit de tekst van ACM dat het dus aan BOA ligt, of iig dat Mozilla een andere manier heeft om dingen te checken, waardoor het nogal traag kan gaan.
Dan moeten wij het dus aanpassen en een beetje vlot als het kan.

Nou, net andersom eigenlijk

Hopelijk ligt het niet aan boa, die nu dus weer aangezet is ipv thttpd.

[Onno]

Floris schreef op 08 augustus 2002 @ 15:26:
Hmm ik begrijp uit de tekst van ACM dat het dus aan BOA ligt,

Bijna goed. Het ligt aan thttpd, Boa deed het juist goed maar wordt niet meer gebruikt. (en straks wel weer dus)

Onno: ik zal mijn leven beteren

Woei!

[ACM]

Onno schreef op 08 augustus 2002 @ 15:32:
(en straks wel weer dus)

Ondertussen dus weer wel
Sinds een paar minuten.

Ik heb (ja nog niet getest met ethereal/welke sniffer dan ook) het idee dat het nu beter is.

[Floor-is]

Onno schreef op 08 augustus 2002 @ 15:32:
[...]
Bijna goed. Het ligt aan thttpd, Boa deed het juist goed maar wordt niet meer gebruikt. (en straks wel weer dus)

Het gemis van BOA, nouja ik had stiekem al gezien dat ACM en kees in gesprek waren over het installeren van BOA op Atlas, dus de link was vrij snel gelegd.

[...]
Woei!

Eh jah lastig hoor

Soms is het wat te technisch voor me en sla ik een stuk van de thread over, maar zoals nu sla ik dan ook wel eens de plank mis zegmaar. Da's nie handig

[Chaos]

Ik heb (ja nog niet getest met ethereal/welke sniffer dan ook) het idee dat het nu beter is.

Yups, het probleem is opgelost. En keep-alive werkt weer zoals het hoort.

[Verwijderd]

Floris schreef op 08 augustus 2002 @ 15:26:
Dan moeten wij het dus aanpassen en een beetje vlot als het kan.

Ja baas That's the spirit..

[André]

He ACM, kan het zijn dat door die update GoT ook perfect werkt op WIN2K+IE5? Want hier had ik veel problemen mee, maar nu ineens werkt GoT perfect. En dat al 3 kwartier...

[ACM]

Yogho schreef op 08 augustus 2002 @ 16:22:
He ACM, kan het zijn dat door die update GoT ook perfect werkt op WIN2K+IE5? Want hier had ik veel problemen mee, maar nu ineens werkt GoT perfect. En dat al 3 kwartier...

Jahoor, alle browsers zullen er in meer of mindere mate last van gehad hebben.

Mozilla dus in veel mate.

[Thijsch]

Cache nog maar een keer per sessie controleren lost hier het probleem op!
(build id: 2002052918) (mozilla 1.0) onder linux woody 2.4.18

[flat]

zeg, ga jij eens vlug je mozilla updaten!

[Thijsch]

Flat© schreef op 08 augustus 2002 @ 22:31:
zeg, ga jij eens vlug je mozilla updaten!

het werkt perfect hier? dus waarom updaten?

[Crazy D]

ParaDot schreef op 08 augustus 2002 @ 22:37:
[...]
het werkt perfect hier? dus waarom updaten?

Omdat je een oude build hebt en omdat het ondertussen weer goed werkt (zie boven)