TTFB erg langzaam*

[Anoniem: 1133443]

Beste mensen,

Op dit moment heb ik een webshop draaide. Ik loop echter tegen één probleem aan. Mijn website is erg sloom, ondanks dat de GT metrix score erg goed is. Het enige wat ik kan ontdekken is dat de TTFB erg langzaam is.

Wie zou mij hier mee kunnen helpen?

- Ik gebruik al plugins zoals Autoptimize en WP Super Cache > alles is geoptimaliseerd.
- Ik heb Strato als webhoster. Ik gebruik het volgende pakket: https://www.strato.nl/hosting/wordpress-hosting/ --> Basic. (Misschien ligt het hier aan?)
- TFFB score --> 5.14 (homepage).

Ik zou nog andere gegevens kunnen delen! Mocht je me willen helpen, dan zou ik dat heel erg waarderen. Ik zou niet weten wat ik moeten doen..

Groeten,
Jetze

[danslo]

Heb je al een profiler geprobeerd? (xdebug, blackfire, etc)

[DJMaze]

Je TFFB ligt aan twee dingen:

1. hosting omgeving
2. WordPress

Ik zou in de diepte kunnen gaan om je alles uit te leggen, maar het lijkt mij verstandiger dat je wat meer € uittrekt om het te verbeteren of zelf de 1000000'en topics over "wordpress traag" eens onderzoekt.

[kamerplant]

Het zal wel door een van de plug-ins komen. Hier is echt zat info over te vinden online.

[Anoniem: 1133443]

Goedemorgen,

Zojuist heb ik een analyse gedaan met UsageDD. De resultaten zijn niet best (zie foto).

Ik ga maar eens uitvogelen hoe ik dit opgelost krijg.. > Toevoeging: Voornamelijk dus de MySQL. Deze is niet normaal hoog.

https://www.mupload.nl/img/qzjuwtkkbrz0.png
https://www.mupload.nl/img/muzi9m.png

[ Voor 12% gewijzigd door Anoniem: 1133443 op 14-08-2019 11:39 ]

[DJMaze]

Anoniem: 1133443 schreef op woensdag 14 augustus 2019 @ 11:09:
Voornamelijk dus de MySQL. Deze is niet normaal hoog.

144 queries is echt niet veel. Dat nummer heb je niks aan.
Een query duurt zeg maar 0.002 s. Dat keer 144 = 0.288 s
Maar niet elke query duurt 0.002 s en dat loopt ook op.
Als een query langer dan 0.03 s duurt moet je op onderzoek (hardware, DB indexes, query opbouw, etc. etc.).

Want de TTFB hier is voor een WooCommerce rond de 450 ms (zonder cache) en 26 ms met.

[ Voor 8% gewijzigd door DJMaze op 14-08-2019 12:08 ]

[Anoniem: 1133443]

Dank voor je reactie. Mijn uitspraak was gebaseerd op de informatie van de plugin ontwikkelaar. Dus ik dacht dat deze erg hoog is

[Freeaqingme]

Maak eens op je hostingpakket een leeg php bestand met als inhoud:

code:

<?php
echo 'hoi';

Als je die pagina opvraagt, dan kan je meten wat die TTFB is. Het verschil met je homepage is de impact van wordpress.

[Anoniem: 159174]

Is hij lokaal ook traag, of alleen bij strato?

[kwaakvaak_v2]

Freeaqingme schreef op woensdag 14 augustus 2019 @ 12:09:
Maak eens op je hostingpakket een leeg php bestand met als inhoud:

code:

<?php
echo 'hoi';

Als je die pagina opvraagt, dan kan je meten wat die TTFB is. Het verschil met je homepage is de impact van wordpress.

Niet helemaal.. Als je dit echt wilt testen zou je een volledige pagina incl. alle assets (js/css/images) moeten opslaan en die opvragen. Op die manier sluit je PHP en MySQL volledig uit en meet je in ieder geval de doorvoer snelheid van de webserver.

[Anoniem: 1133443]

Ik heb de website ooit op een andere server gedraaid. Hier was die heel iets sneller, maar het scheelt niet veel.

Anoniem: 159174 schreef op woensdag 14 augustus 2019 @ 12:33:
Is hij lokaal ook traag, of alleen bij strato?

[Freeaqingme]

kwaakvaak_v2 schreef op woensdag 14 augustus 2019 @ 12:34:
[...]


Niet helemaal.. Als je dit echt wilt testen zou je een volledige pagina incl. alle assets (js/css/images) moeten opslaan en die opvragen. Op die manier sluit je PHP en MySQL volledig uit en meet je in ieder geval de doorvoer snelheid van de webserver.

Dat je er - om te testen - even helemaal een statische website van maakt? Als je doel is om te testen hoe snel/traag wordpress+php+mysql zijn dan kan je dat doen. 't Is alleen net wat je wil testen. Van een statische website waarbij de php interpreter niet ingeladen wordt, heb je mogelijk weer te maken met disk IO latencies, terwijl je die met PHP mogelijk weer niet hebt (opcache die alles in ram houdt).

Het is dus net wat je wil testen. Met wat ik voorstelde heb je dezelfde bottlenecks als wordpress ook heeft, maar dan zonder wordpress/mysql. Op die manier kan je testen hoeveel vertraging de webserver zelf en 't bijbehorende netwerk opleveren.

[Anoniem: 1133443]

Thanks voor jullie antwoorden. Ik denk dat ik al weet waar het aan ligt. Het thema dat ik gebruik (Davinci 2.0) is erg sloom vergeleken met het thema 'Storefront'. Het scheelt zo'n 4 seconden.

[kwaakvaak_v2]

Freeaqingme schreef op woensdag 14 augustus 2019 @ 13:04:
[...]


Dat je er - om te testen - even helemaal een statische website van maakt? Als je doel is om te testen hoe snel/traag wordpress+php+mysql zijn dan kan je dat doen. 't Is alleen net wat je wil testen. Van een statische website waarbij de php interpreter niet ingeladen wordt, heb je mogelijk weer te maken met disk IO latencies, terwijl je die met PHP mogelijk weer niet hebt (opcache die alles in ram houdt).

Het is dus net wat je wil testen. Met wat ik voorstelde heb je dezelfde bottlenecks als wordpress ook heeft, maar dan zonder wordpress/mysql. Op die manier kan je testen hoeveel vertraging de webserver zelf en 't bijbehorende netwerk opleveren.

Opzichzelf wel,alleen met een index.html van een paar bytes ga je nooit de IO latency fatsoenlijk kunnen meten. Dat zou je overigens ook kunnen meten met de productie omgeving als je shell toegang hebt door bij iostat om de seconde te laten zien wat je IO throughput is. (iostat 1)

Persoonlijk denk ik dat de bottleneck meer zit in de afgeknepen of in ieder geval niet op performance getunede omgeving van Strato.

Anoniem: 1133443 schreef op woensdag 14 augustus 2019 @ 13:24:
Thanks voor jullie antwoorden. Ik denk dat ik al weet waar het aan ligt. Het thema dat ik gebruik (Davinci 2.0) is erg sloom vergeleken met het thema 'Storefront'. Het scheelt zo'n 4 seconden.

Haalt dat theme dan veel css/js van een CDN op? Want een thema wat 4 seconden nodig heeft om een template te parsen vind ik wel heel bijzonder? Tenzij het zo'n fancy thema is die de page op display zet nadat alle assets geladen zijn. Want dan blijft je bottleneck nog steeds op server performance hangen. Dan moet je dus met developer tools in chrome gaan checken hoe lang het duurt voor alles geladen is.

[ Voor 23% gewijzigd door kwaakvaak_v2 op 14-08-2019 13:28 ]

[Anoniem: 1133443]

Het is wel gek. Het 'nieuwe' thema laadt een stuk sneller, maar als ik op de demo website van het Davinci thema kijk, dan werkt het allemaal prima. Ergens zit dus een fout, anders zou de demo website ook langzaam moeten werken toch?

Die delevoper tools had ik gisteren bekeken. Daar stond de 'waiting time' op de 5 seconde. Dus het wachten tot de server reageert.

[Anoniem: 1133443]

Een load time verschil van 1.67 seconde vs. 9.98..

[Freeaqingme]

Dan moet je echt je code gaan profilen om dat verder uit te zoeken. Die demo site zou ik vooral naar kijken voor functionaliteit, niet voor snelheid. Het kan heel goed zijn dat zij allemaal (caching) technieken gebruiken die je bij een low-budget partij als Strato niet kan gebruiken.

@kwaakvaak_v2 Het gaat niet alleen om 'een template parsen'. Sommige themes zijn ook weer CMS'en op zich die ook allerlei database queries uitvoeren, op niet altijd even goed geoptimaliseerde tabellen, etc...

[Anoniem: 1133443]

Dus verhuizen naar een andere hosting partij is zeer aan te raden?

[Freeaqingme]

Anoniem: 1133443 schreef op woensdag 14 augustus 2019 @ 15:03:
Dus verhuizen naar een andere hosting partij is zeer aan te raden?

Als jij tevreden bent met een laadtijd van 1.67s, de huidige dienstverlening, en je pricing dan zou ik lekker blijven zitten. Zelfs al zou je geavanceerdere cachingtechnieken kunnen gebruiken, dan moet je ook nog weten hoe je die instelt/configureert. Dat kan je zelf doen, maar dan moet je je wel echt goed inlezen in de materie (of, iemand voor inhuren).

Maar al zou je verhuizen van de ene budgethoster naar de andere, dan kom je qua product vermoedelijk uit op iets wat hier heel veel op lijkt.

Je kan trouwens ook nog kijken naar caching plugins voor Wordpress. Er bestaan een aantal veelgebruikte, en daar kan je wel goede tutorials voor vinden (in ieder geval veel tutorials, zitten vast een paar goede tussen).

[Anoniem: 1133443]

De laadtijd is weer enorm verslechterd. Heeft weer een laadtijd van 10 seconde. Ik snap het niet hoor haha, pff. --> Laadtijd is hetzelfde met een ander thema dus.

[danslo]

Je negeert wel gewoon structureel alle suggesties over profilen. Meten is weten, dus ga kijken waarom je site zo traag is ipv te speculeren over hosting, plugins, thema's, etc.

[DJMaze]

Ik kan prima je probleem oplossen voor €500 en kan je prima hosting partijen melden waar je vanaf €35 per maand zonder zorgen je site kan onderbrengen.
Wil ik dat? Nee, voor mijn gevoel is je budget €2 per maand en stel je daarvoor nu vragen die niet bij het budget passen.

WordPress != Webshop
Kijk eens naar software die geschikt is als webshop en past bij je budget. Scheelt een hele hoop kopzorgen, AVG, exploits en tijd.

Succes!

[Anoniem: 1133443]

Dank iedereen!

[Freeaqingme]

Anoniem: 1133443 schreef op woensdag 14 augustus 2019 @ 15:15:
De laadtijd is weer enorm verslechterd. Heeft weer een laadtijd van 10 seconde. Ik snap het niet hoor haha, pff. --> Laadtijd is hetzelfde met een ander thema dus.

Je zou je vraag eens aan Strato support kunnen stellen, wellicht dat zij nog dingen zien aan hun kant die je kunnen helpen.

Als je meerdere websites hebt dan zou ik wel overwegen die bij verschillende partijen te stallen. Op die manier kan je ervaren wat de verschillen tussen die partijen zijn (niet alleen qua snelheid, maar ook qua dienstverlening).

[Web-Brielle]

Had hetzelfde probleem op mijn VPS met een webwinkel van 15k+ artikelen.
Na veel zoeken besloten om toch een grotere server te pakken. Complete site laad nu in 1.9s en dit vind ik zeer acceptabel (voorheen zomaar 8s als die ook bezig was met een sync).

Een andere hoster / groter pakket is aan te raden.

[ Voor 9% gewijzigd door Web-Brielle op 15-08-2019 11:19 ]

[Ed Vertijsment]

Web-Brielle schreef op donderdag 15 augustus 2019 @ 11:18:
Had hetzelfde probleem op mijn VPS met een webwinkel van 15k+ artikelen.
Na veel zoeken besloten om toch een grotere server te pakken. Complete site laad nu in 1.9s en dit vind ik zeer acceptabel (voorheen zomaar 8s als die ook bezig was met een sync).

Een andere hoster / groter pakket is aan te raden.

9/10 keer is dat niet de oplossing, leuk dat jouw webwinkel nu minder traag is maar waarschijnlijk heb je het onderliggende probleem nog steeds niet opgelost (15k is niet zo veel). De echte oplossing kan iets simpels zijn als ff een index ergens op plaatsen of een vervelende query herschrijven.

Met hardware gooien is doorgaans symptoombestrijding.

Ik wil niet gemeen zijn maar volgens mij mist TS de technische kennis/ervaring om diep in het probleem te kunnen duiken en het te kunnen profilen. Dat is IMO het echte probleem.

[Web-Brielle]

Ed Vertijsment schreef op donderdag 15 augustus 2019 @ 14:54:
[...]


9/10 keer is dat niet de oplossing, leuk dat jouw webwinkel nu minder traag is maar waarschijnlijk heb je het onderliggende probleem nog steeds niet opgelost. De echte oplossing kan iets simpels zijn als ff een index ergens op plaatsen of een vervelende query herschrijven.

Met hardware gooien is doorgaans symptoombestrijding.

Ik wil niet gemeen zijn maar volgens mij mist TS de technische kennis/ervaring om diep in het probleem te kunnen duiken en het te kunnen profilen. Dat is IMO het echte probleem.

In mijn geval was dit wel de oplossing. Aangezien ik meer CPU en RAM ter beschikking heb waardoor ik niet de server te zwaar belast.
Ik kan het snappen dat dit niet zijn probleem hoeft te zijn.

[Ed Vertijsment]

Web-Brielle schreef op donderdag 15 augustus 2019 @ 14:57:
[...]

In mijn geval was dit wel de oplossing. Aangezien ik meer CPU en RAM ter beschikking heb waardoor ik niet de server te zwaar belast.
Ik kan het snappen dat dit niet zijn probleem hoeft te zijn.

Nee, jouw probleem was waarschijnlijk dat een stuk inefficiënte code nodeloos veel CPU/geheugen belast waardoor je nu meer gebruikt dan nodig. Een website hoeft 9/10 niet je CPU uit te maxen of geheugen vol te schrijven, dan doet de software waarschijnlijk iets fout.

Ik raad je dan ook aan om uit te zoeken waarom hij initieel traag was en dat op te lossen, waarschijnlijk draai je dan in je huidige omgeving nog sneller (ik den dat je onder de seconde moet kunnen komen).

Overigens heb je 0 garantie dat je bij 16k producten, of gewoon over een week hetzelfde probleem gaat krijgen.

Ik heb zo'n 3 jaar bij een hoster gewerkt en heb deze discussie vaker gezien dan goed voor me is. Als je denkt dat je een dikke CPU en meer gigabytes aan geheugen nodig hebt om een winkeltje met 15k producten te draaien denk je verkeerd. Je hebt efficiënte software nodig die schaalt en waarbij het niet zo heel relevant is hoeveel records er in je DB staan.

[ Voor 6% gewijzigd door Ed Vertijsment op 15-08-2019 15:04 ]

[Web-Brielle]

Ed Vertijsment schreef op donderdag 15 augustus 2019 @ 15:02:
[...]


Nee, jouw probleem was waarschijnlijk dat een stuk inefficiënte code nodeloos veel CPU/geheugen belast waardoor je nu meer gebruikt dan nodig. Een website hoeft 9/10 niet je CPU uit te maxen of geheugen vol te schrijven, dan doet de software waarschijnlijk iets fout.

Ik raad je dan ook aan om uit te zoeken waarom hij initieel traag was en dat op te lossen, waarschijnlijk draai je dan in je huidige omgeving nog sneller (ik den dat je onder de seconde moet kunnen komen).

Ik heb zo'n 3 jaar bij een hoster gewerkt en heb deze discussie vaker gezien dan goed voor me is. Als je denkt dat je een dikke CPU en meer gigabytes aan geheugen nodig hebt om een winkeltje met 15k producten te draaien denk je verkeerd. Je hebt efficiënte software nodig die schaalt en waarbij het niet zo heel relevant is hoeveel records er in je DB staan.

Ik ga deze discussie niet aan
Maar heb nu 80 sites, waarvan 20 shops draaien die zichzelf syncen met de leverancier.
Als je dan gaat zeggen dat het aan de code gaat liggen, dan zou ik toch een keer eerst meer info vragen ipv zomaar reacties te geven.

Ja, bij mij was het nodig om meer kracht te hebben voor alle sites.
Nee, dit is bij lange na niet altijd het geval.

[AtleX]

Ed Vertijsment schreef op donderdag 15 augustus 2019 @ 15:02:
[...]


Nee, jouw probleem was waarschijnlijk dat een stuk inefficiënte code nodeloos veel CPU/geheugen belast waardoor je nu meer gebruikt dan nodig. Een website hoeft 9/10 niet je CPU uit te maxen of geheugen vol te schrijven, dan doet de software waarschijnlijk iets fout.

Aan de andere kant, geheugen is snel en disk is traag. Ik heb oneindig veel liever dat een applicatie zoveel mogelijk geheugen gebruikt dan dat ik gigabytes aan ongebruikt geheugen heb maar een I/O queue length van hier tot Tokio en weer terug omdat alles maar van disk moet komen.

Ik heb zo'n 3 jaar bij een hoster gewerkt en heb deze discussie vaker gezien dan goed voor me is. Als je denkt dat je een dikke CPU en meer gigabytes aan geheugen nodig hebt om een winkeltje met 15k producten te draaien denk je verkeerd. Je hebt efficiënte software nodig die schaalt en waarbij het niet zo heel relevant is hoeveel records er in je DB staan.

Je vergeet de traffic in dit verhaal. 15000 Producten is misschien niet zo heel veel, maar als 'ie 1000 transacties in een uur heeft en 50000 visits telt dat toch op en daar heb je gewoon genoeg capaciteit voor nodig.

[Ed Vertijsment]

Web-Brielle schreef op donderdag 15 augustus 2019 @ 15:04:
[...]

Ik ga deze discussie niet aan
Maar heb nu 80 sites, waarvan 20 shops draaien die zichzelf syncen met de leverancier.
Als je dan gaat zeggen dat het aan de code gaat liggen, dan zou ik toch een keer eerst meer info vragen ipv zomaar reacties te geven.

Ja, bij mij was het nodig om meer kracht te hebben voor alle sites.
Nee, dit is bij lange na niet altijd het geval.

Als je al zo "op je tenen getrapt" reageert op enkel de suggestie dat de code wellicht wel iets beter zou kunnen weet ik al genoeg. Sorry. Maar iedereens code kan altijd beter, ook die in jouw webwinkel. Bovendien:

Maar heb nu 80 sites

Leuk, we hebben het over 1.

waarvan 20 shops draaien die zichzelf syncen met de leverancier.

Fantastisch, maar de gebeurt niet in request/response en is dus niet relevant.

Sommige van de grootste webwinkels van Nederland/Benelux hebben/hadden exact hetzelfde probleem, (met toch een iets grotere database) en konden ook met ff wat profiling en een kleine tweak, doei zeggen tegen een compleet array van web en db servers en gewoon terug naar een enkele node voor alles.

Ik geef je enkel aan dat naar alle waarschijnlijkheid het daadwerkelijke probleem nog steeds aanwezig is alleen zich even minder nadrukkelijk laat zien.

In alle eerlijkheid boeit mij dat ook bar weinig, jij betaald nu (naar wat ik denk) of teveel, of je site is trager dan nodig, your loss. Wat me stoort is dat je zonder enige kennis van zaken symptoombestrijding die voor jouw in ieder geval tot uitstel heeft geleid voor doet komen als oplossing terwijl dat, zonder de de exacte casus te kennen, tegen zekerheid grenzende waarschijnlijkheid niet de juiste voor het probleem is.

Als een super heavy stressed Magento multistore in < 1s kan laden dan kan een kleine WordPress website dat ook. En nee, CPU en geheugen zijn daar geen grote factoren in. Hoogstens indicatoren.

[Ed Vertijsment]

AtleX schreef op donderdag 15 augustus 2019 @ 15:31:
[...]

Aan de andere kant, geheugen is snel en disk is traag. Ik heb oneindig veel liever dat een applicatie zoveel mogelijk geheugen gebruikt dan dat ik gigabytes aan ongebruikt geheugen heb maar een I/O queue length van hier tot Tokio en weer terug omdat alles maar van disk moet komen.

Absoluut waar, maar tenzij jij Amazon bent heb jij hoogstwaarschijnlijk niet de noodzaak om je volledige systeemgeheugen vol te cachen, los van het feit dat je OS dit al grotendeels voor je doet .

Maar sure, dit zijn optimalisaties die bij kunnen dragen. En als jouw profiling zegt dat je geheugen vol loopt met cache die daadwerkelijk gebruikt, ga voor meer RAM.

AtleX schreef op donderdag 15 augustus 2019 @ 15:31:
[...]

Je vergeet de traffic in dit verhaal. 15000 Producten is misschien niet zo heel veel, maar als 'ie 1000 transacties in een uur heeft en 50000 visits telt dat toch op en daar heb je gewoon genoeg capaciteit voor nodig.

Zelfs dan, niets wat een goede applicatie niet aan zou moeten kunnen. Tuurlijk is het een factor die relevant is maar zelden doorslaggevend.

[Bender]

Anoniem: 1133443 schreef op woensdag 14 augustus 2019 @ 11:09:
Goedemorgen,

Zojuist heb ik een analyse gedaan met UsageDD. De resultaten zijn niet best (zie foto).

Ik ga maar eens uitvogelen hoe ik dit opgelost krijg.. > Toevoeging: Voornamelijk dus de MySQL. Deze is niet normaal hoog.

https://www.mupload.nl/img/qzjuwtkkbrz0.png
https://www.mupload.nl/img/muzi9m.png

Hoe kun je MySQL queries hebben als je website gecached is ;-)

In de praktijk kan dat uiteraard zeker, maar voor een standaard Wordpress website zou dat niet heel logisch zijn. Weet je zeker dat caching goed geconfigureerd is?
(los van het feit dat ik je Strato niet aanraad)

[Wiebeltje]

De juiste oplossing is de code verbeteren. Uitzoeken welke Queries er nu precies langzaam zijn en die fixen ( https://wordpress.org/plugins/query-monitor/ geeft je goed inzicht in de queries en hoe lang ze draaien). Misschien is het maar 1 query die je hele site traag maakt.

Als MySQL het probleem is zou je Redis kunnen proberen als je hoster het ondersteund (ik gok van niet). https://wordpress.org/plugins/redis-cache/ . Deze cached een hoop van je MySQL queries.

WordPress hoeft niet langzaam te zijn maar veel thema's / plugins zijn enorm slecht gebouwd of enorm bloated met features die je niet gebruikt. Plugins die je niet nodig hebt uitschakelen / verwijderen en een lichtgewicht thema zoeken helpt je enorm.

Op zich hoeft het niet erg te zijn als WP traag is als je alleen maar statische content hebt. Dan cache je elke pagina met een goede caching plugin en dan is je WP site ook super snel (omdat die niet eens geladen wordt). Maar met winkelmandjes e.d. wordt dat wel alweer een heel stuk lastiger omdat je dan toch dynamische content nodig hebt.