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/ ?
Tsja, hoe minder vaak je contact hebt met de socket hoe sneller een pagina doorkomt. Iedere send operatie is immers een syscall en syscalls zijn traag. Ook kun je door slim te bufferen en flushen alvast het begin van de pagina renderen en alsnog bezig zijn met uitvoeren van je script.
Oké ... een tijdje terug hadden we het volgens mij ook over output buffering hier ... en ik zei toen ook al dat een aantal jaar eerder output buffering werd afgeraden hier op het forum.
>> 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)?
Output buffering wordt in het algemeen afgeraden omdat het langzaam voelt en het "incorrect programmeren" in de hand werkt. Denk hierbij aan op de verkeerde punten headers versturen etc. Maar slim toegepast kan het sneller voelen. Buffer dus ook niet de gehele layout, maar doe dit in stappen. Zodra je alles voor de header van je site, en met name de css etc in de bron staat kun je flushen, dan kan de browser hier alvast mee aan de slag. Idem voor andere logische elementen.
Zelfs als je niet expliciet ob_start() etc. gebruikt heeft PHP intern verschillende buffers/lagen waartussen gecommuniceerd wordt. Hoe meer je opspaart/mag opsparen hoe minder vaak er geflusht wordt van de ene buffer naar de ander.
Ik snap even niet wat jullie precies bedoelen. Als je (bijv.) het mvc-model hebt dan render je pas op het allerlaatste moment je view (de complete pagina). Bedoelen jullie dat je tussentijds al iets naar het scherm kan sturen?
Het kan wel, maar zeker binnen MVC moet je daar even wat meer voor doen. Het is vaak de moeite niet, want de winst is in milliseconden, al kan de winst in de DOM al snel hoger oplopen, afhankelijk van hoe groot je pagina is.
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. ;-)
