SymLinksIfOwnerMatch performance
Pagina: « vorige 1 2 3 volgende »
- FollowSymlinks staat uit
- SymlinksIfOwnerMatch staat aan
In deze gevallen wordt per path element met lstat() bekeken of het een symlink betreft, dus:
is /home een symlink?
is /home/ozzie een symlink?
etc etc. Als je pad diep genoeg doorloopt is er een meetbaar verschil in performance, maar of dat perceptueel ook aanwezig is durf ik niet te zeggen. Het grootste deel van de request bevindt zich in de applicatie, en wanneer het niet om je applicatie maar om statische bestanden gaat worden deze toch veelal gecached.
Wanneer FollowSymlinks gewoon aan staat wordt alleen op het opgevraagde bestand een stat() call gedaan, om te kijken of deze bestaat.
Lang verhaal kort: in de benchmarks zie je het terug, maar je merkt er eigenlijk niets van.
>> Ik zie zo direct niet echt een waarschuwing staan in het stukje waar je naar linkt, daar wordt enkel uitgelegd wat er gebeurt bij welke instelling.
Die hele pagina met als titel "Apache Performance Tuning" gaat over performance ;-)
Quote:
However, there are compile-time and run-time configuration choices that can significantly affect performance.
>> Waarom zet je niet meteen index.php #2 in de document root ...
Misschien wel omdat index2 de index is van een overkoepelend framework buiten de doc root ;)
@Ben van Velzen
>> ... In deze gevallen wordt per path element met lstat() bekeken of het een symlink betreft ... Wanneer FollowSymlinks gewoon aan staat wordt alleen op het opgevraagde bestand een stat() call gedaan
Is dit een andere uitleg dan jouw eerdere uitleg? Eerder vertelde je dat in beide gevallen lstat wordt uitgevoerd, maar dat bij SymlinksIfOwnerMatch nog de controle op eigenaar plaatsvindt.
>> Als je pad diep genoeg doorloopt is er een meetbaar verschil in performance
Oké ... maar nog even voor de goede orde. Als je index.php in var/www/vhosts/mijnsite.nl staat, dan vinden er dus 4 controles plaats per request ... want als index.php eenmaal geladen is neemt PHP het over en vinden er dus geen controles meer plaats, correct?
En de reden dat je dan een apart index bestand nodig hebt is?
Er bestaat zoiets als set_include_path().
Dit in combinatie met een autoloader = win.
Gewijzigd op 01/06/2016 14:31:02 door Thomas van den Heuvel
> lstat wordt uitgevoerd, maar dat bij SymlinksIfOwnerMatch nog de controle op eigenaar plaatsvindt.
Zoals ik het interpreteer is de uitleg hetzelfde. Althans, in zijn laatste post beschreef Ben wat er gebeurt als FollowSymlinks aanstaat, en in de eerdere post wat er gebeurt als die instelling uitstaat (al lijkt de eerste post iets anders te suggereren, maar dat zal een typo zijn geweest).
Nee, ik heb dat deel alleen weggelaten omdat het voor de performance geen verschil maakt. De systemcall zorgt voor de vertraging. Een simpele if (direntry.uid == uid) is niet langzaam te noemen.
>> Oké ... maar nog even voor de goede orde. Als je index.php in var/www/vhosts/mijnsite.nl staat, dan vinden er dus 4 controles plaats per request ... want als index.php eenmaal geladen is neemt PHP het over en vinden er dus geen controles meer plaats, correct?
5 controles, index.php kan ook een symlink zijn. Verder klopt het helemaal.
Gewijzigd op 01/06/2016 14:33:31 door Ben van Velzen
Autloader lijkt me logisch. Een aparte index omdat ik nog wat specifieke zaken wil kunnen instellen per vhost, maar wellicht iets om over na te denken.
@Ben
Oké. Lang verhaal kort. Dus qua performance maakt het niks uit en kunnen we dus 'veilig' kiezen voor SymlinksIfOwnerMatch in plaats van FollowSymlinks :-)
Gewijzigd op 01/06/2016 14:39:16 door Ozzie PHP
Voor het merken van het veschil maakt het niet uit, als je zware benchmarks gaat doen ga je enkele milliseconden extra zien. Veiligheid kent altijd een prijs, en in dit geval is de prijs dusdanig klein dat je er effectief niets van merkt.
>> Tsja, hoe minder vaak je contact hebt met de socket hoe sneller een pagina doorkomt.
Ik neem aan dat je hiermee bedoelt dat je in plaats van dat je in script A de header echoot en in script B de body en in script C de footer, dat je beter alles in een variabele kunt stoppen en alles pas aan het eind in 1x echoot (even simpel gezegd)?
Bad performance kills good sites. Je kunt beter éérst een cachingstrategie uitstippelen, voor server én client. Dan kom je er misschien ook achter, afhankelijk van de gekozen strategie, dat je een Content-Length header nodig hebt voor een persistent connection. En dat is best lastig: de lengte van content bepalen als je die content nog moet genereren. ;-)
Pagina: « vorige 1 2 3 volgende »