[PHP] Pagina's als het ware "cachen"

[Verwijderd]

Ik heb een ideetje, om de laadtijd van pagina's op m'n website zo veel mogelijk te beperken.

Op de bedachte manier sla ik pagina's letterlijk op in een bepaalde dir, en check ik bij elk bezoek of de "opgeslagen file" up to date is met de content (bij dynamische pagina's; check database datum en bij "normale pagina's" dmv filemtime).

Mits de opgeslagen file nog up to date is, laad de opgeslagen file. Zo niet; laad dan de werkelijke PHP file en "cache" deze door de output ervan te overschrijven op de vorige "opgeslagen file".

Ik hoop dat het zo een beetje begrepen wordt

Echter voordat ik hiermee allemaal ga beginnen, zou ik toch graag willen vragen of dit een goede en effectieve manier zou zijn?

Bijvoorbaad dank.

[Verwijderd]

kijk is naar accelerator paketten voor php,
doen precies wat jij wil met nog wat meer manieren.

[stfn345]

Ik doe het zelf anders.. ik parse mijn php scripts om de zoveel tijd naar html, dus 1x in de zoveel tijd hoeft er maar geupdate te worden

je zou die parser aan kunnen roepen vanuit scripts die ervoor zorgen dat wijzigingen worden gedaan, dus na de wijziging meteen een keer parsen

[kvdveer]

Dat hangt af van de mate waarin je pagina's dynamisch zijn. Als je bijvoorbeeld op iedere pagina een willekeurige DB-entry laat zien, zal die pagina altijd herladen moeten worden. Ook als je site met veel variabelen werkt, zul je heel veel pagina's op moeten slaan. Dit zul je zelf moeten beoordelen.

Lees ook het volgende artikel eens door. Misschien is het voor jou een betere optie
http://www.phpbuilder.com...unner20011113.php3?page=1

[Verwijderd]

Verwijderd schreef op 23 februari 2003 @ 12:15:
kijk is naar accelerator paketten voor php,
doen precies wat jij wil met nog wat meer manieren.

http://www.php-accelerator.co.uk/download.php

Zoiets zul je vast bedoelen? O.a. dit en de APC-tool die ik gevonden had via de search hier. Moeten allemaal worden gecompileerd ofwel geinstalleerd worden op de betreffende server. Echter heb ik daar bij mijn host niet de mogelijkheid voor (om bijv. alleen al de php.ini file te bewerken).

RaZoRhEaD schreef op 23 februari 2003 @ 12:16:
Ik doe het zelf anders.. ik parse mijn php scripts om de zoveel tijd naar html, dus 1x in de zoveel tijd hoeft er maar geupdate te worden

je zou die parser aan kunnen roepen vanuit scripts die ervoor zorgen dat wijzigingen worden gedaan, dus na de wijziging meteen een keer parsen

Dit zou opzich niet echt een optie zijn, omdat ik liever via FTP werk. En op die manier moet ik alles via het web doen. Dus ook bepaalde *.php files bewerken via een online editor.

Ik maak wel een admin om bijv. bepaalde data toe te voegen aan de database, maar om alles direct via het web te bewerken (gezien je de bepaalde files bij opslaan moet bijwerken) vind ik minder...

kvdveer schreef op 23 februari 2003 @ 12:18:
Dat hangt af van de mate waarin je pagina's dynamisch zijn. Als je bijvoorbeeld op iedere pagina een willekeurige DB-entry laat zien, zal die pagina altijd herladen moeten worden. Ook als je site met veel variabelen werkt, zul je heel veel pagina's op moeten slaan. Dit zul je zelf moeten beoordelen.

Lees ook het volgende artikel eens door. Misschien is het voor jou een betere optie
http://www.phpbuilder.com...unner20011113.php3?page=1

Inprincipe sla ik via de methode elke pagina op, en dat zal volgens mij niet echt een probleem worden... (of ik moet je verkeerd begrijpen)

Ik ook eens even naar het artikel kijken.

[DRvDijk]

Smarty is een template-parser die hetzelfde idee implementeerd.. Misschien handy?

[Verwijderd]

Het gegeven dat Smarty ook cached had ik iig ook al gevonden met de search hier. Alleen is het zo dat ik liever bij de template parser blijf die ik op dit moment gebruik (TemplatePower)...

Maar als ik het dus goed begrijp (uit de links) is het misshien wel beter (overzichterlijker enz.) om het via MySQL te doen?

[Verwijderd]

Proxy server ertussen zetten?

[Verwijderd]

Verwijderd schreef op 23 februari 2003 @ 19:53:
Proxy server ertussen zetten?

Hoe bedoel je precies...?

[WouZz]

Volgens mij worden hier een aantal methodes om te "cachen" door elkaar gehaald. Cachen kan je op verschillende niveau's doen.. Bijvoorbeeld: Het cachen van het parsen en compilen van PHP scripts (bv door PHP-Accelerator), het "parsen" van templates (Smarty), database results sets (DBMS), script executies (voorstel topicstarter) en output/html (Proxy server).

Het is dan natuurlijk afhankelijk van de situatie op welk niveau je wilt cachen. Bijvoorbeeld of je content vaak gewijzigd wordt, hoe persoonlijk je pagina's zijn, hoe complex je queries enz.. Bovendien is het altijd de vraag of een bepaalde methode om te cachen ook daadwerkelijk een significante snelheidswinst oplevert.

[Verwijderd]

Die situatie die jij schets impliceerd dat er eigelijk bijna nooit updates zijn. Biedt die delen dan standaard als html aan.

[Postman]

De manier geschetst in de topicstart is op zich een goede manier, behalve dan dat je per keer gaat controleren of de file wel up-to-date is. Dit vertraagd het dus eigenlijk weer. Je kunt dus beter om de zoveel tijd kijken of alle pagina's wel up-to-date zijn en ze zo nodig bij werken. Doe dit dan via een apart script en crontab. Op die manier krijgt de bezoeker meteen de gevraagde pagina te zien (je hebt immers alleen maar HTML en hoeft niet eerst nog van alles te controleren/bij te werken). Tijdsinterval hangt af van je content. Veranderd die erg vaak dan is een interval van 10 min. wel iets, anders 1 uur of langer.

[goalgetter]

Opzich heb je gelijk als je zegt dat een call naar filemtime() weer tijd kost, maar ik denk niet dat de vertraging in afwikkeling van de request dusdanig groot is dat je het moet meenemen. Met de door de topicstarter gekozen oplossing heb je weliswaar elke keer die "vertraging" maar heb je nooit een verouderde pagina.

Het kan opzich wel een afweging zijn als je echt kritisch kijkt naar je response times, maar ik betwijfel of het significante verschillen geeft. Ik denk dat het zinvoller is om een onderscheid te maken tussen pagina's die je wel wil cachen en pagina's die je nooit wil cachen (fora e.d.).

[Soultaker]

Het is natuurlijk ook verstandig om je expiration en cache control headers goed in te stellen, en rekening te houden met header only requests (geen idee hoe dat in PHP gaat, trouwens). Als je dat goed geregeld hebt, zou je het feitelijke cachen kunnen delegeren naar een bestaande HTTP proxy server, die op basis van die headers prima kan beslissen wanneer 'ie een full request moet doen. Bijkomend voordeel is dat je niet alleen op de processorkracht maar ook op bandbreedte bespaart, omdat clients nu ook op een zinnige manier kunnen cachen.

Het is altijd een goed idee om algemene oplossingen te beschouwen, voordat je begint met het programmeren van een specifieke oplossing voor een probleem dat feitelijk al eens eerder opgelost is.

(Ik ben het dus met 00fly747 eens).

[ Voor 20% gewijzigd door Soultaker op 24-02-2003 01:12 ]

[Rense Klinkenberg]

Zoals hierboven al aangegeven is, is het belangerijk om naar cache headers te kijken. Verder moet je ook kijken naar browsers die een 'If-modified-since' header meesturen, aangezien je daar eventueel een 304 - Not midified header naar terug kan sturen.

Om je wat werkt te besparen, zou je voor een deel ook gebruik kunnen maken van PEAR::Cache_Lite of PEAR::Cache. De eerste is speciaal gemaakt voor het cachen m.b.v. bestanden, terwijl PEAR::Cache uitgebreider is in mogelijkheden om te cachen en om de cache in op te slaan.

Op ONLamp.com staat een duidelijk artikel over hoe PEAR::Cache te gebruiken is en daar staat ook een voorbeeld van een oplossing voor de situatie die je hier schets.

[Verwijderd]

Aangezien ik vooralsnog niet veel kennis heb van de andere alternatieven die hierboven worden genoemd. Kan ik beter eerst m'n eigen idee uit proberen en dan later eventueel altijd nog op de andere manieren terug komen...

Zal ik eens een versie schrijven van m'n eigen idee, om te kijken of de snelheidswinst die er geboekt wordt het ook wel waard is om het te doen.

[drm]

Markuz:
Aangezien ik vooralsnog niet veel kennis heb van de andere alternatieven die hierboven worden genoemd. Kan ik beter eerst m'n eigen idee uit proberen en dan later eventueel altijd nog op de andere manieren terug komen...

Stiekem vraag ik me dan een beetje af waarom je het nou precies ter discussie gesteld hebt hier

HTTP biedt, zoals boven beschreven toch aardige alternatieven voor een zelf bedacht systeem, en je kunt aan de hand van verscheidene tooltjes als bijv. ethereal bekijken of je scripts functioneren zoals je wilt (het bekijken van de HTTP headers), zodat het testen van een client-side caching systeem (op basis van de headers) eigenlijk een eitje wordt.

Zal ik eens een versie schrijven van m'n eigen idee, om te kijken of de snelheidswinst die er geboekt wordt het ook wel waard is om het te doen.

Als je 't mij vraagt: probeer het eerst op basis van HTTP, en mocht dat dan niet lukken kun je altijd nog uitwijken naar je eigen (server-side caching) systeem

[Verwijderd]

drm schreef op 24 February 2003 @ 08:58:
Stiekem vraag ik me dan een beetje af waarom je het nou precies ter discussie gesteld hebt hier

Nou, de primaire vraag was of "mijn idee" een effectieve manier zou zijn om een redelijk snelheidswinst te bewerkstelligen...

drm schreef op 24 February 2003 @ 08:58:
Als je 't mij vraagt: probeer het eerst op basis van HTTP, en mocht dat dan niet lukken kun je altijd nog uitwijken naar je eigen (server-side caching) systeem

Ik heb ondertussen even een snelle test kunnen uitvoeren, en vooralsnog is de snelheidswinst miniem (0,05 sec)...

Volgende vraag die ik dan zou willen stellen; hoe maak je zoiets op basis van HTTP?

[Verwijderd]

Kick

[chris]

zoek eens op headers enzo....

rfc

<sub>cache-control

klik niet hier</sub>

[ Voor 77% gewijzigd door chris op 25-02-2003 01:52 . Reden: toch nog wat hints toegevoegd ]