Ik kamp al een tijdje met lange time to first byte op een website dat ik opgeleverd had aan een klant op basis van wordpress. In het kort: een internationale website met verkoop producten in combinatie met een eigen server (4 cores / 8GB), litespeed enterprise licentie en cloudflare CDN voor juist het internationale verkeer. Ik heb echt het onderste uit de kan gehaald uit wat nog verder mogelijk is zoals

- Extra geheugen toegewezen aan litespeed
- Alle controles op updates eruit gesloopt in wordpress
- Met litespeed caching de gehele website aangepakt geoptimaliseerd
- De wp_actionscheduler_logs leeggeflikkerd, limit van maximaal 2 dagen aan entries (waarom the fuck zit dit in Woocommerce?)
- De database handmatig nagelopen op eventueele rest entries en verwijderd
- Compacted, optimized, 1 dag retentie m.b.t revisies

Ook aan de kant van Cloudflare het e.a aangepakt, een redelijke DDOS bescherming ingesteld, maar ik kan niet te "ver" gaan want dan wordt ook legitiem verkeer zoals DHL en toestanden geblokkeerd.

Iedere maand is het wel raak. De website raakt echt vertraagd (QueryMonitor) rapporteert soms 9 seconden laadtijd in de wp-admin alleen al. Op de frontend is het ook niet echt bijster snel. Kijk ik in de database dan staan er gerust 150k aan logs gegenereerd in o.a wp_actionscheduler_logs. Maar ook het mandje van gasten of leden raakt natuurlijk vol op ten duur. Woocommerce slaat alles feitelijk op en daarmee groeit die database explosief.

Ik heb Redis object cache even geprobeerd, er zat een snelheidswinst in maar het gaat mis op de varianten van een product. Bijv 50ml, 100ml, 150ml, 200ml etc en laat alleen 1 van de bijv 5 opties zien. Ik kan dat ook niet finetunen heb ik het idee, anders dan een betaalde versie aan te schaffen.

Ik dacht dat litespeed altijd de holy grail was aangezien ik zelf ook licenties heb staan op m'n eigen servers. En dat werkt gewoon goed. Dat heb ik in de loop der jaren maanden mooi fine weten te tunen. De CPU load van die server staat gemiddeld op 0%. Het is een server dat van Transip vandaan komt. Het is ook dichtgetimmerd qua security en bruteforce aanvallen worden niet alleen afgewend middels litespeed maar ook op cloudflare niveau (challenge).

Iemand tips? En dan niet van die schijt optimalisatie en toestanden waar je een plugin voor nodig hebt. Het probleem is de time to first byte. En als het laadt laadt het ook direct goed. Dat is dan weer het aparte. Het is dus sporadisch. Mischien dat Cloudflare cache regelmatig flushed en opnieuw alles moet ophalen. Ik heb geen idee.

Niet direct een oplossing voor de trage queries (querymonitor), maar ik lees nergens iets van een CDN voor je internationale verkeer (naast Cloudflare). Maar ik ben ook geen expert op het versnellen van WP sites.

1x in de zoveel tijd klinkt alsof je cache op dat moment verlopen is? Misschien dat de crawler van cloudflare je cache warm kan houden zodat het minder/niet gebeurt ?

Het is het free pakket bij Cloudflare, dus het zou me niets verbazen. Free houdt in dat het maar 1x per dag crawled. en images worden bijv niet optimized. Maar ik gebruik webp conversie al; ik zeg onsite is alles al gedaan en aangepakt wat maar kan. Je krijgt als je browser het ondersteund gewoon webp voorgeschoteld.

Het is echt die time to first byte, het moment dat je een adres intikt en een pagina tevoorschijn krijgt. TTFB is meestal te wijten aan een drukke server, maar dat ding draait op bekant 0% CPU usage. PHP 7.4 staat erop, litespeed enterprise, extra vergrote caches ingesteld etc.


Mijn serverbeheerder schrijft net ClamAV te hebben vervangen met maldet, en merkt al in Directadmin een verbetering alleen al (reageert directer). Het lijkt nu op het eerste oog wat rapper maar soms merk ik 4 seconden tijd nog door bladeren van producten heen.

Origineel gepost door J van der Linde

Iedere maand is het wel raak. De website raakt echt vertraagd (QueryMonitor) rapporteert soms 9 seconden laadtijd in de wp-admin alleen al.

Heb je ook een hoge Inodes verbruik?

Origineel gepost door J van der Linde

Op de frontend is het ook niet echt bijster snel. Kijk ik in de database dan staan er gerust 150k aan logs gegenereerd in o.a wp_actionscheduler_logs. Maar ook het mandje van gasten of leden raakt natuurlijk vol op ten duur. Woocommerce slaat alles feitelijk op en daarmee groeit die database explosief.

Full page cache probleem

Als ik de database weer op weet te ruimen, is het gehele probleem ook weer weg. Het is dus zo goed als te wijten aan de groeiende database.

We gaan even de boel overzetten van een Xeon gold naar een AMD Epyc.

Origineel gepost door J van der Linde

Als ik de database weer op weet te ruimen, is het gehele probleem ook weer weg. Het is dus zo goed als te wijten aan de groeiende database.

Je hebt denk ik al de auto clean up aan staan van Litespeed denk ik he?
Maybe custom scriptje schrijven die elke nacht een clean draait als het probleem echt daar ligt?

In de regel mag het geen reet uitmaken of die database nu 800MB of 3GB groot is. Ik heb shops gedraaid waar de database over tijd op meer dan 8GB zat. En nog wat de performance "subliem". Maar een beetje entries en het zaakje loopt gelijk vol lijkt wel.

Ik ga alleen in op de basis van je vraag "Wat is de perfect omgeving voor WordPress" want over de rest kan ik niet oordelen zonder link om te testen.
Punt is dat het niet gaat om de omgeving zoals servers en dergelijk maar het gaat altijd om de website. Je kan een super snelle website bouwen op een goedkope hosting. Daar is in mijn ogen echt geen super snelle server voor nodig in 99/100 van de websites.
Maar we kunnen dieper ingaan op de omgeving door te kijken naar wat je allemaal gebruikt aan plugins en welke plugins maar ook welke gebruiken veel de database en hoe is de website en database gebouwd.
Ik hoor heel veel van die dingen over servers, CPU, enz enz. maar aan de andere kant overbelasten ze de website met iets dat niet eens echt nodig is. Dat is waarom ik hier niet verder op in ga. De meeste hier weten veel van servers en dergelijken en ik niet omdat ik websites op een andere manier bekijk. Mensen die denken dat alles draait om de omgeving denken niet na over hoe de website is opgebouwd en hoe het werkt want ik heb deze server en dit en dat en dus moet ik er alles kunnen doen wat ik wil en dan moet het nog snel zijn ook. Zo werkt dat dus niet.

Wordpress vergt gewoon veel. Een kale installatie op gewoon PHP draaien vergt 150MB geheugen per bezoeker om 1 pagina te spawnen. Om maximale performance eruit te halen moet je wel met Litespeed of Ngix werken. Dat zijn aangepaste en zwaar getweakte apache / PHP varianten die veel efficienter omgaan met resources en vooral alle pagina's die wordpress er normaal uitpoept in een soort cache bewaren. Het serveren hiervan is natuurlijk 100x sneller dan wanneer alles realtime geparsed moet worden.

Ik heb voor mijn gevoel alles al gedaan wat ik had kunnen doen, en nog werkt het niet goed. Ik heb of gebruik veel plugins, dat moet helaas. Ik had ook liever de website op een stand-alone PHP configuratie willen bouwen maar de website is bij mij ondergebracht met het verzoek te restylen op basis van wat er al staat. Dus dan moet je gewoon (leren) werken met wat je hebt. Server cores, snelheid en RAM is zeker belangrijk. Bij wordpress al helemaal. Het zaakje kakt gewoon in als je het ff druk hebt. Ik denk dat je zelf ook eens met wordpress moet stoeien om een idee te krijgen van wat het doet.

Anyway; we gaan het migreren naar een Epyc gebaseerd platform, en ik verwacht dat het ook stukken beter zal gaan draaien omdat de CPU snelheid op 2.6Ghz vs 2.2Ghz ligt en de cache van de CPU (wat juist belangrijk is bij veel database applicaties) een stuk hoger is. Het is ook een volledige reinstall van linux inclusief litespeed, directadmin en PHP 7.4.

Inmiddels overgezet op een AMD Epyc; het hele probleem is opgelost. Denk dat Intel gewoon te oud aan het worden is.

Hmm, wel gek. Ligt eraan welke. Mag ik vragen welke Xeon je draaide?

De ene series was op 2.4Ghz, de andere nu Epyc op 2.6Ghz en met wat meer cache dan de Intel variant. Vooral in database intensieve taken scheelt dat gewoon veel.

Anderhalve maand verder, alle problemen als sneeuw voor de zon opgelost.

Hoef ook geen periodieke onderhoud meer uit te voeren als in het opruimen van de enorm gegroeide database niks.

Als het zo lang duurt, vraag ik me af of er wel gecached wordt. Dan bedoel ik echt caching en rewriten.