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/ ?
Ook dat inderdaad, een goed cachingmodel werkt vele malen beter dan met zaken spelen die niet goed in je applicatie passen. Ik heb sites gebouwd met varnish ervoor om complete inhoud te cachen, of fragmenten via edge side includes. Het Symfony framework levert iets vergelijkbaars met de HttpCache module, en dat kan ook heel interessant zijn. het enige waar je goed voor moet uitkijken is dat je je cache goed op orde moet hebben. Het laatste dat je wilt is dat je de verkeerde data doorstuurt. Je kunt dit met ETags doen of Last-Modified, whatever floats your boat. Zoals Phil Karlton zei: There are only two hard things in Computer Science: cache invalidation and naming things.
Persistente connecties kom je vaak nog wel omheen omdat je dit op twee manieren kunt doen. Met de eerder genoemde Content-Length header, maar ook met Content-Transfer-Encoding: chunked. De laatste is gebruikelijker, en dit is ook wat PHP standaard doet.
Ik begrijp nu nog steeds het 'principe' niet wat er bedoeld wordt met die output buffering. Ik weet dan ook niet of we het over hetzelfde hebben.
Stel we hebben (laten we het even simpel houden) 3 afzonderlijke html/php files waarmee we een pagina opbouwen: header.phtml, page.phtml en footer.phtml
Is het nu beter/slimmer om vanuit een index.php deze pagina's achter elkaar te includen, of is het beter om ze te bufferen en dan in 1x te flushen?
Is het nu beter/slimmer om vanuit een index.php deze pagina's achter elkaar te includen, of is het beter om ze te bufferen en dan in 1x te flushen?
None of the above. Het is geen simpele keuze tussen A of B, maar iets dat je moet profilen.
Dat begint met de waterval in de developer tools van je browser, want daarin kun je meestal vrij snel zien wat de bottleneck is.
Als je naar verschillende use cases kijkt, zie je bijvoorbeeld op de lange lijn van piepkleine respons naar supergrote respons vaak ergens een omslagpunt waar een andere vorm van buffering en compressie sneller wordt. Het laden van een grafisch zware portfoliosite vol foto's is appels en een Ajax-request beantwoorden is peren: die kun je niet met elkaar vergelijken.
Compressie vereist bovendien content negotiation: de client bepaalt welke smaak compressie te behappen is. En niet elke client is hetzelfde, ook dat nog.
Als je ruimere vuistregels zoekt, zijn er wel wat breekpunten waarop je de buffer kunt flushen en content naar de client moet verzenden.
• De Time to First Byte (TTFB) is kritiek voor de beleefde snelheid. De TTFB is mede daarom belangrijk voor SEO. Aangezien je éérst headers moet verzenden en pas daarna content, kun je de outputbuffer flushen na de laatste aanroep van header().
• Je benut parallelle connecties op de client beter als je die zo snel mogelijk aan het werk zet. Dat geldt vooral voor het ophalen van CSS- en JavaScript-bestanden in de <link>- en <script>-tags: heb je die compleet, dan kun je de outputbuffer flushen. Het kan daarnaast wat ander ongemak beperken, zoals een FOUC (Flash Of Unstyled Content).
• Voor de user experience is het belangrijk dat bezoekers zo snel mogelijk beeld hebben. Nou ligt de paginavouw typisch ook zelden op elk device op dezelfde plek, maar zodra je één scherm vol beeld hebt boven de vouw, kun je de outputbuffer flushen.
• Browsers kunnen pagina's sneller renderen als de DOM-documentstructuur eerder compleet is. Ook daarin zit een mooi breekpunt voor het flushen van de outputbuffer: DOM compleet, dan direct aanbieden.
Interessant verhaal. Ik ben hier zelf eigenlijk nooit mee bezig geweest. Kan me ook niet herinneren dat de programmeurs bij mijn voorgaande werkgevers hier rekening mee hielden. Wel interessant om me eens beter in te verdiepen.
Moet ik me dan voorstellen dat je eerst ob_start() gebruikt, dan een aantal requires/includes doet en dan ob_flush()? En dan weer verder met ob_start(), weer wat requires/includes en dan weer ob_flush() enz. ?
@admins deze thread is (toegegeven, mede door mijn opmerking) een beetje een eigen leven gaan leiden, tijd om ontopic te blijven of een nieuwe thread te openen?
