php en cachen

[_arno_]

Hallo heren,

Ik heb wat zitten lezen over optimalisatie van je site, nu komt het onderwerp cache omhoog.

Nu vond ik het wel interessant om te maken en heb ik een cache systeem gecreeerd voor mijn website.

Wat doet het:
checken of cache bestand bestaat en binnen de validation time valt, zo ja output het , zo niet maak nieuw bestand aan.

Nu merk ik helaas geen verschil op mijn webserver omdat mijn website niet bezocht word.

Nu vraag ik me af, heeft het uberhaupt zin?
Gebruiken jullie ook zoiets dergelijks?
Is er merkbaar verschil bij hoge aantallen bezoekers, en hoe hoog zijn deze aantallen dan?

[Wido]

Cachen, mits goed gedaan heeft het zeker nut.

Had een klant die deed 100 queries naar de SQL server op zijn index.

Na wat uitleggen over cachen liep het ineens stukken vlotter.

En niet voor alles zijn zo maar cijfers beschikbaar.

[dee2005]

ja caching heeft zin, iig voor mij.

voor dat ik caching had, was een load van 7 normaal. met caching nu een load onder de 2.

[V. Kleijnendorst]

Denk ook eens aan client-side cache. Een 304 geven kan heel wat dataverkeer en parsingtijd schelen. Vrij éénvoudig te realiseren met bijvoorbeeld een DATETIME kolom in je tabellen.

[_arno_]

304 error, als ik het goed begrijp vertel je met een 304 dat de client deze request al heeft en die up to date is?

[V. Kleijnendorst]

Jup. Als je ervoor zorgt dat je de juiste headers geeft (last-modified en etag), dan kan de client deze cachen. Bij een vervolg request vergelijk je de if-modified-since en etag met de eerder gegeven headers. Bij een overeenkomst geef je een 304 header (is overigens geen error) en doe je een exit.

Op php.net doen ze het zonder ETag; niet helemaal volgens de standaard, maar werkt wel:

http://www.php.net/source.php?url=/index.php

[_arno_]

Nu vraag ik me af, heeft een 304 eigenlijk zin.

Het wezelijke verschil is dat de user nu geen data ophaalt vanaf de server.
Het enige wat je dus zal merken is het verschil in data verkeer?
Parse tijd is zowiezo al bijna nihil met cache systeem ( mits goedgedaan ), enige wat het doet is 1 if statement en outputten.

Zou jij zeggen als je het echt goed wilt doen kun je beter client-side cachen?
Maar nu vraag ik me af, is dit wel betrouwbaar?

[V. Kleijnendorst]

Een combinatie kan mooi zijn, de uitvoering hangt van de website af.

Client-side caching is zeer betrouwbaar, eigenlijk speel betrouwbaarheid geen rol. Als een client de if-modified-since en ETag stuurt, dan kun je deze vergelijken met je opgeslagen ETag en last-modified. Zijn ze hetzelfde dan kan/mag/moet je ervan uit gaan dat de client deze pagina (of bestand) in het cache geheugen heeft bewaard. (de http specificatie)

Doordat je na een 304 header niets hoeft weer te geven scheelt dat naast dataverkeer natuurlijk ook belasting van de webserver.

Op fora en weblogs zijn er nog al eens wat bezoekers die de pagina iedere paar minuten refreshen om te kijken of er nieuwe reacties zijn gekomen op een bericht. Dan kan iedereen wel uitrekenen hoeveel database queries client-side cachen kan schelen.

[_arno_]

Zeer interessant,

Als ik het goed begrijp op php.net vult hij eerst de array $timestamps met de modificatie tijden van de betreffende files en pak daar de hoogste van( includes en zichzelf ).

als hij dus weet dat de timestamps van de modificatie times hetzelfde is als de client side cache timestamp, laat hij de client side cache zien.
Zo niet output header last modified.

Maar wat ik niet begrijp is hoe komen ze aan: $_SERVER[HTTP_IF_MODIFIED_SINCE]
Is dit header(last modified) ?

[V. Kleijnendorst]

De client stuurt $_SERVER[HTTP_IF_MODIFIED_SINCE] mee bij een aanvraag als je zelf eerst een header hebt gegeven:

header("Last-Modified: " . $tsstring);

Bij PHP.net gebruiken ze de laatste wijzigingsdatum van een include. In de praktijk zul je een query op je database los moeten laten die je de laatste wijziging uit een tabel teruggeeft.

[_arno_]

Ok ik ga hier mee spelen,
Bedankt voor je kennis mr Kleijnendors!

[roland]

Als je een pagina hebt waarin aardig wat db queryies zitten waarvan de content niet vaak gewijzigd wordt kan het zeker lonen om die pagina (of deel van) te cachen in een database/txt bestand.

Als er iets wijzigd wordt in de content leeg je de cache van die pagina, zo niet laat je het er lekker in staan.

Dit heeft enkele voordelen tegen over alleen een 304 te gebruken:
- er hoeft maar 1 bezoeker te komen zodat het geached wordt, voor alle bezoekers erna hoeven de db queries niet meer uitgeveord te worden.
- db wordt minder belast
- pagina laadt sneller, minder parse tijd

Als je een site hebt waar de content zeer regelmatig wijzigt en weinig bezoekers komen werkt dit natuurlijk in het nadeel.

Dit systeem heb ik in meerdere sites verwerkt en het voordeel is merkbaar aan de bezoekers kant en aan de kant van de server.

[edit] je kan natuurlijk een combinatie maken met dit systeem en 304, minder db query en caching aan de kant van de bezoeker. Bezoekers die de pagina niet hebben belasten de server minder en hebben de pagina sneller. Wat wil je nog meer?

[Pier]

Optimaal is om de pagina's ook nog gzipped te versturen, maar ETags icm gzipped content werkt helaas niet op IE5 en 6, deze bug zou wel gefixt moeten zijn in de komende beta van IE 7.

Er zijn al een aantal php-caches die precies doen wat jij beschrijft,
zie bijvoorbeeld http://www.jpcache.com/ (volledige pagina's) en Turck MMCache (saves compiled code).