Archief - Performance issues

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
D

Dubbelpunt

Legacy Member
vlug vraagje:
kunnen 3rd party scripts zoals google analytics, percentMobile, clickTale,... de website vertragen?
a

adrianhates

Legacy Member
Webber zei:
vlug vraagje:
kunnen 3rd party scripts zoals google analytics, percentMobile, clickTale,... de website vertragen?
Klik om te vergroten...

ja maar niet zozeer als die AJAX implementatie van jullie
C

Cycloon

Legacy Member
Webber zei:
vlug vraagje:
kunnen 3rd party scripts zoals google analytics, percentMobile, clickTale,... de website vertragen?
Klik om te vergroten...

Ja, daarom dat je die scripts ook best laat laden op het einde van de pagina.
D

Dubbelpunt

Legacy Member
TriMenToR zei:
True. Vooral die laatste is op jullie website duidelijk ook een probleem (ook geen ETags). De stylesheets, JS files en de statische afbeeldingen worden al niet gecached. Bovendien bevindt de CSS zicht niet volledig bovenaan (Haal die inline CSS er ook uit!!).
Klik om te vergroten...

hoe kan ik alles doen cachen?
wat zin ETags?

eerste keer dat ik hoor dat de css volledig bovenaan moet trouwens


TriMenToR zei:
Klik om te vergroten...

vanwaar haal je dit toch allemaal?
b

bugoff

Legacy Member
zware database servers: veel geheugen waardoor het meeste gewoon in het geheugen zit, grote query cache, ...
D

Dubbelpunt

Legacy Member
wij hebben de oorzaak gevonden denk ik, onze programmeurs zijn nogal fan van procedureel, en dus hebben ze onze hoofdmodule zo geprogrammeerd

op onze website kan je bieden, en daarbij wordt 1 file opgeroepen die 11.000 lijnen code bevat... daarom dat onze website enorm traag wordt aan het einde van de veiling (als er veel users zijn en dus ook vele biedingen)
a

adrianhates

Legacy Member
opsplitsen in modules en modules specifieker aanroepen zou de oplossing zijn dan :)
D

Dubbelpunt

Legacy Member
het probleem is opgelost (dankzij een audit van een php expert), maar we hebben echter nog 1 probleem: als we nieuwe machines uploaden moet er dus nieuwe data geladen worden, dit duurt voor een nieuwe bezoeker 20 tot 30 seconden! Echter, nadat alles in cache is gezet, dus bij een tweede bezoek, wordt alles geladen in minder dan 500 ms!

Wat kunnen we er aan doen om alles sneller te doen laden bij een eerste bezoek aub?
T

TiZon

Legacy Member
Webber zei:
het probleem is opgelost (dankzij een audit van een php expert), maar we hebben echter nog 1 probleem: als we nieuwe machines uploaden moet er dus nieuwe data geladen worden, dit duurt voor een nieuwe bezoeker 20 tot 30 seconden! Echter, nadat alles in cache is gezet, dus bij een tweede bezoek, wordt alles geladen in minder dan 500 ms!

Wat kunnen we er aan doen om alles sneller te doen laden bij een eerste bezoek aub?
Klik om te vergroten...

Zelf laten cachen direct na de update van de gegevens?
D

Dubbelpunt

Legacy Member
wat bedoel je? de client moet toch eerst alles terug downloaden? de sql enzo moet toch uitgevoerd worden vanaf 0?
T

TiZon

Legacy Member
inderdaad, maar als je dit proces nu zelf doet. Dan moet de eerste gebruiker dit toch niet doen en heeft hij hier toch geen last van...
D

Dubbelpunt

Legacy Member
ik heb totaal geen idee hoe ik dit moet doen,
ik ken enkel de oplossing ENABLE CACHE in het CMS dat we gebruiken
X

Xavez

Legacy Member
Heel jullie site is echt absurd groot. Véél overvloedige HTML en CSS, afbeeldingen, ... I mean

HTML: 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
D

Dubbelpunt

Legacy Member
idd, we zijn er aan bezig om dit allemaal op te kuisen, zou dit invloed hebben op de performance? en dan spreek ik over enkele seconden, niet over milliseconden

TiZon zei:
inderdaad, maar als je dit proces nu zelf doet. Dan moet de eerste gebruiker dit toch niet doen en heeft hij hier toch geen last van...
Klik om te vergroten...

Hoe doe ik dit TiZon? wij gebruiken Joomla btw...
a

adrianhates

Legacy Member
hoe meer html je laadt hoe langer het zal duren , logisch.
De &nbps; zullen niet veel kwaad doen , het zijn eerder de afbeeldingen die voor de seconden zorgen.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan