Initial load is traag

[Gropah]

De laatste tijd heb ik steeds vaker dat het langer duurt voor een pagina op tweakers laad. Hier een voorbeeld van mijn bookmarks:



Zoals te zien duurt het 4,5 seconde om de pagina op te halen. Het is geen cache miss oid, want dit trad op na een aantal keer te verversen om dit te reproduceren en een screenshot te kunnen maken. Sinds dat mij dit opvalt is er niets bij mij intern veranderd en ik lijk er last van te hebben op zowel desktop als mobiel en mobiel via wifi en 4g.

Ik zou zelf zo niet weten wat voor info jullie nodig hebben om dit te fixen, of dat het wellicht toch aan mij ligt. Wat data die ik mij voor kan stellen dat kan helpen:

Firefox 68.0 op desktop (windows 10 en Ubuntu 16.04)
Firefox mobile 68.0 op Oxygen 9.0.6 (Android 9.0)
speedtest komt op 70mbit down, 20mbit up met een ping van 9ms.

[Raven]

Zitten de browsers soms te wachten op cijfers.tweakers.nl danwel scorecardresearch voordat de pagina volledig geladen is? Dat gebeurt hier namelijk nog wel eens, ik kan de pagina dan grotendeels zien (embedded YT-filmpjes dan nog niet), Firefox geeft dan een tijdje "wachten op *zie-eerder-genoemde-domeinen*" aan. Het gekke is, het gebeurd ook wanneer beide in de hostfile met 127.0.0.1 erachter staan

[ Voor 4% gewijzigd door Raven op 13-07-2019 14:24 ]

[Jorick]

Je kunt kijken of hetzelfde zich voordoet in een andere browser om uit te sluiten dat het probleem niet bij Firefox ligt. Probeer ook even of je het in Firefox kunt reproduceren middels privenavigatie om uit te sluiten dat er toch niet iets mis gaat met cache. En wat voor resultaat krijg je als je pingt naar tweakers.net? Wat verder nog de moeite waard kan zijn om te proberen is om een andere DNS zoals bijvoorbeeld OpenDNS te gebruiken om te kijken of het probleem daarmee verdwijnt of niet. Dit kun je in vrijwel iedere browser wel instellen of desnoods op OS niveau.

[crisp]

@Raven als jij geen (web)server lokaal hebt draaien die op poort 443 luistert dan is het logisch dat toevoegen aan je hostfile met ip 127.0.0.1 geen soelaas biedt

@Gropah heb je ook de volledige lijst? Hieruit kan ik niet opmaken wat er nu precies zo lang duurt.

Edit: ah, de pagina (html) zelf dus. Ik vermoed dan een query die er lang over gedaan heeft. Sinds we geupgrade zijn naar MySql 8 zien we dat vaker, de oorzaak zijn we nog aan het onderzoeken...

[ Voor 26% gewijzigd door crisp op 13-07-2019 14:36 ]

[alex3305]

@crisp Dit issue werd geloof ik een tijdje geleden ook al gerapporteerd, maar kan het niet direct meer terugvinden. Zelf heb ik hier namelijk ook sporadisch last van. Vooral bij de eerste keer GoT laden lijkt het e.e.a. soms erg lang te duren.

Het gebeurt hier met de laatste Chrome op Windows 10 met een Ziggo verbinding, mocht dat interessant zijn.

[Gropah]

crisp schreef op zaterdag 13 juli 2019 @ 14:28:
@Gropah heb je ook de volledige lijst? Hieruit kan ik niet opmaken wat er nu precies zo lang duurt.

Als ik een recente load moet geloven is het wachten op de server:



Maar ik zal je een DM sturen met een HAR file. Lijkt me niet handig die publiek te plaatsen, want ik weet niet wat voor info er allemaal in staat, maar kan me voorstellen dat daar ook cookies etc in worden genoemd.

edit nav jouw edit: dat zou het inderdaad kunnen zijn, maar het is niet consistent binnen dezelfde minuut wat mij redelijk raar lijkt als het door een query is. Het is jammer dat je niet weet waarom de query lang duurt anders zou je wellicht delen kunnen cachen oid.

[ Voor 20% gewijzigd door Gropah op 13-07-2019 14:52 ]

[crisp]

Gropah schreef op zaterdag 13 juli 2019 @ 14:40:
[...]

edit nav jouw edit: dat zou het inderdaad kunnen zijn, maar het is niet consistent binnen dezelfde minuut wat mij redelijk raar lijkt als het door een query is. Het is jammer dat je niet weet waarom de query lang duurt anders zou je wellicht delen kunnen cachen oid.

Het is ook niet constant. Als ik in de slow query logs kijk zie ik wel met regelmaat de list_bookmarks query terugkeren. An sich is het een snelle query, maar blijkbaar duurt hij af en toe een seconde of 3. Wellicht heeft het iets te maken met de 'CREATE TEMPORARY TABLE' maar daar moeten we dan verder onderzoek naar doen.

We hebben afgelopen week MySQL geupgrade naar versie 8 en hebben dit soort performance issues ook bij andere queries opgemerkt. Het kan zijn dat het load-gerelateerd is en daardoor niet continue speelt, maar ook dat is iets wat we nog verder moeten uitzoeken. We zijn hier in ieder geval de afgelopen dagen al mee bezig geweest, maar het blijkt lastig om een specifieke oorzaak te isoleren (behalve de nieuwe versie dan ).

[InFamous]

@crisp ik heb deze vertraging ook regelmatig bij de myreact pagina. Ik heb dit helaas niet kunnen loggen omdat ik voornamelijk op mijn telefoon zit.

[crisp]

InFamous schreef op zaterdag 13 juli 2019 @ 20:59:
@crisp ik heb deze vertraging ook regelmatig bij de myreact pagina. Ik heb dit helaas niet kunnen loggen omdat ik voornamelijk op mijn telefoon zit.

Als dat ook iets sinds de afgelopen week is dan zal dat inderdaad gerelateerd zijn..

[InFamous]

Correct, dit speelt pas een week +-, dacht eerst aan mijn internet verbinding maar het gebeurde voornamelijk op de myreact pagina.

Ter verduidelijking deze pagina dus https://gathering.tweakers.net/forum/myreact/
Vaak is het een seconde of 2 maar soms echt een seconde of 6.

[ Voor 36% gewijzigd door InFamous op 13-07-2019 22:56 ]

[HollowGamer]

InFamous schreef op zaterdag 13 juli 2019 @ 20:59:
@crisp ik heb deze vertraging ook regelmatig bij de myreact pagina. Ik heb dit helaas niet kunnen loggen omdat ik voornamelijk op mijn telefoon zit.

Dan moet je even remote debugging aanzetten.

Gelukkig ben ik niet de enige, al merk ik op Firefox Preview wel minder vertraging, al is die engine wel helemaal opnieuw opgebouwd en minder 'bloat'.

[Kees]

Ik heb (vanmorgen) nog wat getuned, in de stats lijkt het sneller te gaan nu.

[Gropah]

Het lijkt te helpen, maar heel af en toe heb ik er nog een te pakken die er 2750+ ms over doet