Ondanks dat ik FollowSymLinks (via Plesk) heb uitgeschakeld, werkt rewriting nog steeds. Ik ga er dus vanuit dat SymLinksIfOwnerMatch op een hoger niveau wél is ingeschakeld. Als ik nu de bovenstaande link lees, dan staat daar dat er telkens wordt gecontroleerd op eigenaar.
Wat ik nu niet begrijp uit de documentatie ... stel, ik zet in mijn index.php het volgende:
require '/var/www/framework/index.php';
Gaat ie dan voor iedere map de eigenaar checken, ook als het géén symlink betreft? Of gebeurt dit alleen als het wél een symlink betreft? Bijv. als ik dit zou doen:
require '/framework/index.php';
... waarbij /framework dan een symbolische link is naar /var/www/framework/ ?
Oké, dus als ik je goed begrijp ... als ik /var/www/framework en de symlink beiden als root aanmaak is er niks aan de hand, maar als ik een van beiden als user ozzie aanmaak, dan werkt het niet als SymlinkIfOwnerMatch is ingeschakeld?
Maar dit speelt dus alleen bij de aanroep TOTDAT index.php in de doc root is geladen? En daarna maakt het niet meer uit? Dus als index.php is geladen en ik roep van daaruit de symlink 'framework/index.php/' aan, dan maakt het niet uit als de symlink door root is gemaakt en de map door ozzie?
[size=xsmall]Toevoeging op 30/05/2016 17:40:15:[/size]
Oh ja, als het enkel om het stukje tot aan index.php gaat dan neem ik aan dat het qua performance niet echt uitmaakt of je SymlinkIfOwnerMatch of FollowSymlinks gebruikt? Aangezien Apache op haar website voor performanceverlies waarschuwt??
Op beide vlakken is het antwoord: correct. lstat() is een relatief langzamen systemcall, maar omdat het resultaat uit lstat alle informatie die betrekking heeft op FollowSymlinks en SymlinksIfOwnerMatch is de performance gelijk. Alleen de uitwerking is anders. Wanneer je FollowSymlinks uit hebt staan vindt de controle plaats, wanneer deze aan staat niet. Wanneer SymlinksIfOwnerMatch aan staat vindt controle plaats, en wanneer deze uit staat wordt nog steeds gecontroleerd of je symlinks in het pad hebt staan. Voor de performance is er dus weinig tot geen verschil.
PHP heeft geen notie van de Apache configuratie, en doet als zodanig niets met symlinks. Ze worden gewoon gevolgd. Zolang de user toegang heeft tot de bestanden die je opvraagt met require, include of aanverwanten worden deze gewoon geopend.
Oh ja, als het enkel om het stukje tot aan index.php gaat dan neem ik aan dat het qua performance niet echt uitmaakt of je SymlinkIfOwnerMatch of FollowSymlinks gebruikt? Aangezien Apache op haar website voor performanceverlies waarschuwt??
Om die performance hoef je je denk ik niet zo druk te maken. De webserver op mijn werk heeft vandaag (vrij rustige dag ;-) ) een kleine 2 miljoen requests afgehandeld en praktisch elke request loopt door een of meerdere symlinks. Daar komt nog eens bij dat het een virtuele machine is die een groot deel van de requests via een reverse proxy laat afhandelen door webservers op andere virtuele machines (die ook aan elkaar hangen van symlinks). De content wordt vervolgens dynamisch gegenereerd door een script dat data uit een database ophaalt, in XML-formaat zet en door een XSLT-parser haalt die er HTML van maakt. En dat alles zonder noemenswaardige vertraging.
Ik heb geen idee vanaf welke getallen het performanceverlies merkbaar zou moeten zijn. Ik ben het in ieder geval nog niet tegengekomen. De voornaamste reden dat op piekmomenten onze performance inzakt is doordat onze gigabit-uplink het niet meer trekt.
Thanks voor je toelichting Willem. Fijn om te horen. Wel vreemd dan dat de website van Apachte er voor "waarschuwt". Beetje storm in een glas water dan ...
Thanks voor je toelichting Willem. Fijn om te horen. Wel vreemd dan dat de website van Apachte er voor "waarschuwt". Beetje storm in een glas water dan ...
Ik sluit niet uit dat die alinea een jaar of 20 geleden is geschreven, toen een dergelijke instelling nog wel merkbaar kon zijn voor je performance. :-)
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. Ook staat daar niet dat een bepaalde instelling catastrofaal is voor performance maar simpelweg dat er meer controles plaatsvinden. Indien dit echt een deuk in je performance zou slaan zou hier wel een melding over gemaakt worden. En als performance echt een issue is (high traffic site) dan heb je hier al andere voorzieningen voor getroffen (load balancing etc.).
Je moet je ook blijven afvragen waar je (veel) winst kan pakken he. Mogelijk is het beste wat je kunt halen met het spelen met deze instellingen een micro optimalisatie. Die mogelijk weer teniet wordt gedaan door brakke code of trage queries.
Zo begrijp ik bijvoorbeeld niet (als dit echt een concrete situatie is en niet enkel bedoeld was ter illustratie) dat je vanuit index.php #1 index.php #2 required. Waarom zet je niet meteen index.php #2 in de document root en laad je de rest dynamisch in met behulp van een autoloader (en dus niet met require of include)? Indien dit een concreet geval was dan zit naar alle waarschijnlijkheid de echte bottleneck nog altijd in de applicatie zelf. Weinig optimalisatie hieromheen zal dat verhelpen :).
