Web server performance TTFB TTLB

[Verwijderd]

Vraagje omtrent web site performance.

Ik heb een dedicated webserver 6 Cores 3,06 ghz, 24 Gb geheugen, raid 10 set van 300 GB Sas disken.

Nou zit er 1 website tussen die traag is. De website (wordpress) in kwestie is op zich qua database niet groot.
Echter het laden duurt inderdaad soms lang. Nou heb ik allerlei tooltjes en performance testen gedaan. Er is een grote wait time van soms 3 a 4 seconden,en de ttfb is waarde F ( slecht volgens een aantal sites).

Na wat onderzoek ben ik toch eens gaan kijken of andere sites op de server dit ook hebben. Dat verschilt nogal. Een html site heeft een A grade (goed) van de ttfb, een andere wordpress site krijgt een B, redelijk goed. De connectietijd naar de server zelf is snel. Er zijn meerdere websites die een F grade krijgen, echter de een laad toch weer sneller dan de andere.

De server draait rond de 15 a 20 % cpu, IO is ook niet schokkend hoog, memory is voor de helft in gebruik.

Mijn mening is dat voornamelijk de wordpress sites met zwaardere/grotere thema`s een vertraging oplopen.
Als ik ga zoeken naar TTFB oplossingen dan kan ik ongeveer de hele server tunen in de hoop dat het zich oplost, echter het feit dat sommige sites binnen een flits laden en andere traag laden en de ttfb grades nogal wisselen zijn lijkt het mij logisch dat sommige thema`s gewoon een zwaardere belasting op de webserver/database leggen.

Heeft iemand hier ervaring mee ?


...

[WeHoDo]

Schakel eens wat plugins uit.
En probeer het daarna nog eens.

Trage WordPress ligt vaak aan (teveel) plugins of plugins die brak zijn.

[André]

Ik vermoed net als WeHoDo dat er een plugin is die zorgt voor de vertraging. Dus of je moet de boosdoener opzoeken, of een goede caching plugin installeren. Dan hoeft de server alleen maar simpele HTML uit te serveren zonder gebruik te maken van de database.

[gitaarwerk]

Wordpress is ontzettend traag als inderdaad een paar foute plugins staan, soms kan het ook zijn dat de site in developer mode staat (ik had iets met logging eens, en toen ging de server op z'n muil , was zo een meertaligheid plugin).

TTFB op PHP vs simple HTML zou wel een indicatie moeten geven ja.

Dus ik voeg me bij de anderen.

[DJMaze]

WordPress kan "redelijk" zijn zonder plugins. Ik host er 3 en allemaal rond de 250ms response.
Dit gebeurt puur met PHP-FPM 7.2 en SSD. Geen Varnish, NGINX, etc.

Ik zeg redelijk omdat andere PHP websites die ik host op 30ms zitten.

Dus ja, zelfs zonder plugins is WordPress geen snelheidsmonster en zou ik als ik jou was je er niet druk om maken en lekker zo laten.

[gitaarwerk]

DJMaze schreef op dinsdag 12 juni 2018 @ 13:05:
WordPress kan "redelijk" zijn zonder plugins. Ik host er 3 en allemaal rond de 250ms response.
Dit gebeurt puur met PHP-FPM 7.2 en SSD. Geen Varnish, NGINX, etc.

Ik zeg redelijk omdat andere PHP websites die ik host op 30ms zitten.

Dus ja, zelfs zonder plugins is WordPress geen snelheidsmonster en zou ik als ik jou was je er niet druk om maken en lekker zo laten.

Indeed, en vergeet niet, misschien niet het geval hier, dat een TLS handshake ook wat tijd in beslag neemt.

[DJMaze]

gitaarwerk schreef op dinsdag 12 juni 2018 @ 14:49:
dat een TLS handshake ook wat tijd in beslag neemt.

Soms wel soms niet. Zelfde pagina 2x geladen. Eerste keer snel, tweede daarentegen....

[gitaarwerk]

Session resumption kan veel doen. Nog steeds wordt dat niet altijd ondersteund :-)

Bij ons via amazon aws kan het soms nog steeds 1seconden duren met TLS met TTFB. Helaas niet altijd heel veel aan te doen.

[DJMaze]

gitaarwerk schreef op dinsdag 12 juni 2018 @ 21:46:
Bij ons via amazon aws kan het soms nog steeds 1seconden duren met TLS met TTFB. Helaas niet altijd heel veel aan te doen.

Je kan de OCSP checken. Hier een biased document maar het verklaart het wel.
https://www.digicert.com/...d-what-they-mean-for-you/

[gitaarwerk]

DJMaze schreef op dinsdag 12 juni 2018 @ 23:31:
[...]

Je kan de OCSP checken. Hier een biased document maar het verklaart het wel.
https://www.digicert.com/...d-what-they-mean-for-you/

Ik ben zelf niet verantwoordelijk hiervoor, maar het klinkt alsof het wel sneller zou moeten kunnen. Wat bij ons (coolblue) wel waar is dat 100ms daadwerkelijk ook echt 1% conversie kost. Maar sowieso is het vaak wel voor initieel request, maar die is toch wel heel erg belangrijk. Maar misschien iets teveel details voor dit topic

Hier staat ook wel wat meer betreft de verscheidene manieren; https://www.fir3net.com/S...rtificate-revocation.html moet het zelf nog lezen.

[_Thanatos_]

Als het opzetten van TLS lang duurt, kun je HTTP/2 gebruiken. Dan worden verbindingen niet afgesloten maar meerdere files achter elkaar over dezelfde HTTP(S)-verbinding gestreamt.

Support daarvoor is fantastisch tegenwoordig. Oude browsers krijgen dan gewoon HTTP/1.1.

[ Voor 27% gewijzigd door _Thanatos_ op 13-06-2018 12:29 ]

[gitaarwerk]

_Thanatos_ schreef op woensdag 13 juni 2018 @ 12:27:
Als het opzetten van TLS lang duurt, kun je HTTP/2 gebruiken. Dan worden verbindingen niet afgesloten maar meerdere files achter elkaar over dezelfde HTTP(S)-verbinding gestreamt.

Support daarvoor is fantastisch tegenwoordig. Oude browsers krijgen dan gewoon HTTP/1.1.

Denk dat je twee dingen door elkaar haalt hier

HTTP/2 kan alleen (volledig) ondersteund worden middels HTTPS. TLS is een protocol om te zorgen dat je verbindingen beveiligd en over HTTPS lopen. Ook files achter elkaar laden is het niet helemaal, maar zodra je van de server documenten opvraagt (meestal via html), kun je bijvoorbeeld een stream openen met alle afbeeldingen die direct vanuit het document worden opgevraagd. Of je gebruikt server push (dan stuur je alle content gelijk mee met het document, waardoor je geen extra requests meer hoeft te doen, maar de praktische implementatie is pittig; iets met caching en invalideren hiervan).

Maar in ieder geval, een time to first byte kan erg vertraagd worden door de TLS handshake. Er zijn verschillende settings en manieren, helaas hebben ieder eigen voordelen en nadelen.

[_Thanatos_]

IE11 is de enige browser die TLS vereist voor HTTP/2. De rest kan ook unencrypted HTTP/2. Maar daar gaat het niet om.

Ik las dat het maken van de TLS handshake lang kan duren. Als je HTTP/1.1 gebruikt, worden er veel vaker nieuwe verbindingen opengetrapt, en (dus?) een aantal extra TLS handshakes. HTTP/2 doet ook nog aan parallel downloaden, maar houdt z'n verbindingen in leven waardoor er (dus?) minder TLS handshakes nodig zijn.

Toch? Of wordt een TLS-verbinding sowieso opengehouden, ongeacht de laag erboven (HTTP/1.1) die verbinding eruit kan gooien?

[Spinal]

_Thanatos_ schreef op woensdag 13 juni 2018 @ 14:03:
IE11 is de enige browser die TLS vereist voor HTTP/2. De rest kan ook unencrypted HTTP/2.

Nope. Alle browsers die HTTP/2 doen, vereisen daarvoor TLS.

[_Thanatos_]

Oh shit nou zie ik het
M'n eigen link nota bene

Nouja, het gaat hier om TLS, dus eigenlijk maakt het niet eens uit dat TLS verplicht is.

[b2vjfvj75gjx7]

DJMaze schreef op dinsdag 12 juni 2018 @ 13:05:
WordPress kan "redelijk" zijn zonder plugins. Ik host er 3 en allemaal rond de 250ms response.
Dit gebeurt puur met PHP-FPM 7.2 en SSD. Geen Varnish, NGINX, etc.

Ik zeg redelijk omdat andere PHP websites die ik host op 30ms zitten.

Dus ja, zelfs zonder plugins is WordPress geen snelheidsmonster en zou ik als ik jou was je er niet druk om maken en lekker zo laten.

Grappig, nooit echt op de response time gelet van mijn eigen WP sites... maar ik zit rond de 125ms.

Nog niet snel, maar goed... het kan dus redelijk zijn indd...

- edit - geen cache / ssd / whatever... gewoon plain custom-build WP.

- edit2 - als ik test-locatie verander van US / Singapore naar EU / London zit ik op 60ms - kan dus ook wel schelen.

[ Voor 15% gewijzigd door b2vjfvj75gjx7 op 14-06-2018 18:41 ]

[gitaarwerk]

Niet heel slecht hoor. Je kan ook nog static pages gaan serveren