In het verleden heb ik wel eens een vergelijkbare vraag gesteld, maar ik ben benieuwd hoe jullie er vandaag de dag tegenover staan.
De vraag luidt: wat controleer jij?
Ik zag zojuist in een ander topic dat iemand alvorens een view te includen ging controleren of de view wel bestaat. Op zich niks mis mee, maar hoe ver ga jij hierin? Controleer jij ALTIJD of een bestand aanwezig is alvorens je het gaat parsen of laden? Ook als je zeker weet dat dat bestand gewoon altijd aanwezig is? En wat doe je met bijv. met configuratiesettings die je ophaalt op basis van hun ID? Haal je die gelijk op omdat je weet dat de setting bestaat? Of controleert jouw get() functie stiekem nog even of je wel een geldige ID hebt ingegeven?
Als je toch een controle gaat bouwen, waarom dan niet een kleine applicatie schrijven die de integriteit van alle kritieke bestanden controleert? Bijvoorbeeld md5_file() wordt vaak gebruikt voor downloads: heeft een bestand een andere MD5-hash gekregen, dan is het gewijzigd. Je hoeft dan niet allerlei klassen en applicaties vol te stoppen met controles, maar voert op een hoger niveau een volledige "server integrity check" uit. Kun je meteen mee controleren of je server niet gecompromitteerd is.
Oeh... dat lijkt me een mooi project voor "ooit" :-) Hoe zou je zoiets moeten aanpakken dan?
Voor nu gaat het me om iets heel simpels. Bijvoorbeeld, iemand roept de pagina www.mijnsite.nl/contact aan. Als je dan de bijbehorende view/template gaat laden, zou je dan wel of niet file_exists() gebruiken om eerst te controleren of die view bestaat? Of laad je de view/template direct in?
Oeh... dat lijkt me een mooi project voor "ooit" :-) Hoe zou je zoiets moeten aanpakken dan?
Voor nu gaat het me om iets heel simpels. Bijvoorbeeld, iemand roept de pagina www.mijnsite.nl/contact aan. Als je dan de bijbehorende view/template gaat laden, zou je dan wel of niet file_exists() gebruiken om eerst te controleren of die view bestaat? Of laad je de view/template direct in?
Doe het dan meteen goed. Een contactpagina is typisch iets dat zelden verandert. Die haal je dus op uit je file cache. De rest komt er pas in twee situaties aan te pas bij een cache-update: als de contactgegevens veranderen óf als de template verandert (en die verandering meer behelst dan een aanpassing van een CSS-bestand).
Daarna pas is de volgende vraag aan de orde. Aangezien je view/template nu alleen nog maar eens in de zoveel maanden hoeft aan te spreken voor een cache-update, kun je daarin inderdaad prima file_exists() gebruiken óf een uitstapje maken naar je eigen FileSystem-klasse. Dat kost overhead, maar voor één request per zoveel maanden speelt dat geen rol.
Gaat het dan fout, door een ontbrekend bestand, dat blijf je de cache gebruiken en stuur je een noodkreet-mailtje naar de webmaster.
Bouw geen losse klassen maar denk in oplossingen. Wat je links weglaat, moet er rechts soms bij. Wat je nu niet doet, moet je later alsnog doen.
Hmmm, oké... maar ook als je de contactpagina uit de cache zou halen, moet je een bestand ophalen. En zeker bij een cache-pagina lijkt het me handig om te kijken of de cache wel bestaat. Dus dan krijg je daar alsnog een file_exists. Of mis ik nu iets?
Inderdaad, in de cache is file_exists() onmisbaar. Sterker nog, je zult soms ook nog de datum en tijd van het cachebestand willen controleren om na te gaan of het cachebestand niet verouderd is, dus is hiervoor nog een uitstapje langs het filesystem nodig.
Hangt ervan af welke beslissingsregels je voor de TTL van de cache instelt. De grootste snelheidswinst boek je met een clientcache, maar daarvoor moet je per verzoek controleren of de versie op de server niet actueler is dan de versie op de client.
Controles zijn soms overbodig. Je kunt bijvoorbeeld elke nacht via een cronjob de complete cache vernieuwen of elk uur de oudste 10% updaten. Verzin maar een werkbare beslissingsregel.
Je kunt de controle buiten het filesystem om doen door een last-modified te registreren bij de content in de database. Achterom wil je als admin vaak ook nog een cache-update kunnen forceren, bijvoorbeeld omdat je een template hebt aangepast.
Wel nuttig om daar eens naar te kijken, want je kunt er gigantische snelheidswinst mee boeken, tot een factor 10. Bij elk HTTP-verzoek een complete HTML-pagina in elkaar fietsen met queries en echo's is minder vanzelfsprekend dan het lijkt.
