php en image caching

[HenkS]

hallo

ik heb het volgende:

een fifa-league online gemaakt waar mensen die fifa spelen meedoen aan een ranglijst.

je ziet in de league dus de stand, maar ook een clublogo (ongeveer 25kb groot per stuk) waarvan je er per league dus 20 hebt iedere keer.

nu heb ik alle images in de database weggeschreven (dus niet op schijf), ik haal dus steeds de league uit de database op met alle bijbehorende images.

De plaatjes veranderen eigenlijk nooit, alleen de positie waar ze staan op de site wel.

Kan ik alleen de images cachen terwijl de volgorde waarin ze staan toch dynamisch is? Ik heb op deze site en google gezocht op php cache en op html cache maar kom er niet echt uit. Kan iemand me anders even op weg helpen waari k kan kijken. Het zelf uitzoeken vind ik niet erg, maar ik wil graag de goede richting in geholpen worden

bedankt

[RobIII]

Je zit qua caching wel goed inderdaad, maar waarom zou je statische content (die dan weliswaar uit de DB komt) 'nogmaals' willen cachen? Cachen (server-side) heeft enkel nut bij dynamische content waarvoor je bij iedere pageview weer je resources flink belast. Het ophalen van een image uit de DB of van een schijf valt daar nou niet echt onder (aangenomen dat je DB verder wel fatsoenlijk in elkaar steekt). Iedere image afzonderlijk kun je zien als statische content (en dus boeie in welke volgorde die staan). Het is de uitgespuugde gegenereerde content die het cachen (misschien) waard kan zijn.

Wat eerder nut zal hebben is zorgen dat client-side alles juist gecached wordt.

[ Voor 27% gewijzigd door RobIII op 22-09-2008 12:16 ]

[HenkS]

tnx voor je reactie

een vraag mbt client side caching:

heeft dit wel nut, want als ik de images en rest van de content uit de database haal, dan moet je toch al de query doen om de data op te halen.

waarom zou je dan nog client side cachen? dat is me niet duidelijk.

Want stel:

ik haal 20 images op van 25kb = 500kb. Ik wil eigenlijk voorkomen dat voor iedereen die de league bekijkt deze 500kb moet ophalen.

Maar als ik in de query dan toch al doe iets als : "select image, teamname, .... From ...." dan haal ik toch sowieso al die data op.

Voorkomt client-side caching dan toch dat deze 500kb uit de db moet worden geladen en/of getoond? dit begrijp ik niet helemaal

[Erkens]

HenkS schreef op maandag 22 september 2008 @ 12:45:
Voorkomt client-side caching dan toch dat deze 500kb uit de db moet worden geladen en/of getoond? dit begrijp ik niet helemaal

Client-side caching is handig als de gebruikers vaker dan 1x je pagina bekijkt. Waardoor ze dus bij de volgende request niet meer die 500kb hoeven te downloaden.

[HenkS]

Erkens schreef op maandag 22 september 2008 @ 12:48:
[...]

Client-side caching is handig als de gebruikers vaker dan 1x je pagina bekijkt. Waardoor ze dus bij de volgende request niet meer die 500kb hoeven te downloaden.

dat begrijp ik, alleen wat ik me afvraag: als desbetreffende gebruiker vaker op mijn pagina komt, en ik haal met mijn query toch al de images op uit de database. wordt die 500kb dan toch al niet geladen? of wordt dit alleen dan server side geladen, maar wordt het client side uit de cache gehaald?

kort om: wat gebeurt met de 20 images die ik met de query uit de db haal, als iemand de plaatjes client-side uit de cache ophaalt?

[Erkens]

HenkS schreef op maandag 22 september 2008 @ 12:57:
kort om: wat gebeurt met de 20 images die ik met de query uit de db haal, als iemand de plaatjes client-side uit de cache ophaalt?

Als de client die plaatjes niet opvraagt hoef je ze toch ook niet uit de DB te trekken?

[lawnmower]

HenkS schreef op maandag 22 september 2008 @ 12:57:
[...]
kort om: wat gebeurt met de 20 images die ik met de query uit de db haal, als iemand de plaatjes client-side uit de cache ophaalt?

Je browser checked eerst of hij zelf de nieuwste versie van de image heeft, zo niet dan haalt hij deze op.

Als de client die plaatjes niet opvraagt hoef je ze toch ook niet uit de DB te trekken?

En inderdaad, deze vertraging zul je hoe dan ook altijd hebben.. of je client ze nu cached of niet.

[ Voor 22% gewijzigd door lawnmower op 22-09-2008 13:06 ]

[Cloud]

Ik weet niet precies hoe client-side caching werkt, maar als de url van het plaatje hetzelfde is zal de browser het niet nogmaals opvragen als er al een lokale kopie in de cache bestaat. En dus wordt je database ook niet geraadpleegd

[HenkS]

tnx, ik hoef dus niks extra's te doen?

kan ik ergens in de browser (mozilla bv) checken of een plaatje uit de cache is geladen of niet?

[Kettrick]

HenkS schreef op maandag 22 september 2008 @ 13:06:
tnx, ik hoef dus niks extra's te doen?

kan ik ergens in de browser (mozilla bv) checken of een plaatje uit de cache is geladen of niet?

Dit kan je redelijk makkelijk checken met firebug, enorm handig om te zien wat er gedownload wordt.
(en nog 100 andere handige functies, zeker een aanrader ).

[lawnmower]

Als je je plaatjes op schijf opslaat, en alleen de filename in de DB opslaat voorkom je in ieder geval de (vele) kb's dataflow vanaf je DB iedere keer als dat niet nodig is.

[Janoz]

Ik ben eigenlijk wel benieuwd hoe je je gegevens verwerkt. Je hebt het de hele tijd over 1 query waarmee je de gegevens ophaalt. Dat kan twee dingen betekenen:
1 - Ik begrijp het verkeerd/jij verteld het wat vreemd
2 - Je bent dubbel werk aan het doen.

De hele content en de plaatjes komen als aparte requests binnen. Ik zou dus eerder verwachten dat je een query hebt met daarin de gegevens zonder plaatje, en vervolgens per plaatje weer een request, dus query om het plaatje op te halen.

[HenkS]

Janoz schreef op maandag 22 september 2008 @ 13:10:
Ik ben eigenlijk wel benieuwd hoe je je gegevens verwerkt. Je hebt het de hele tijd over 1 query waarmee je de gegevens ophaalt. Dat kan twee dingen betekenen:
1 - Ik begrijp het verkeerd/jij verteld het wat vreemd
2 - Je bent dubbel werk aan het doen.

De hele content en de plaatjes komen als aparte requests binnen. Ik zou dus eerder verwachten dat je een query hebt met daarin de gegevens zonder plaatje, en vervolgens per plaatje weer een request, dus query om het plaatje op te halen.

ik denk dat ik het niet zo goed uitleg

ik doe een query waarbij ik meerdere velden ophaal.

het plaatje toon ik vervolgens zo:

<IMG SRC=plaatje.php?plaatje_id=$row[4]>

waarbij ik in plaatje.php het volgende heb staan:

PHP:

$plaatje_id = $_REQUEST['plaatje_id'];
Header( "Content-type: image/jpeg");
$sql = "SELECT team_shirt FROM team WHERE team_id=$plaatje_id";
$result=mysql_query($sql) or die("Can't Perform Query");
$row=mysql_fetch_row($result);
echo $row[0];

zo toon ik dus het plaatje, ik weet niet of op deze manier uberhaupt ooit van de client-cache gebruik wordt gemaakt?

[Erkens]

Cloud schreef op maandag 22 september 2008 @ 13:04:
Ik weet niet precies hoe client-side caching werkt, maar als de url van het plaatje hetzelfde is zal de browser het niet nogmaals opvragen als er al een lokale kopie in de cache bestaat. En dus wordt je database ook niet geraadpleegd

ul opzich zegt niet zoveel, het gaat om welke http headers mee gestuurd worden waaraan de browser kan checken of een nieuwe versie moet worden gedownload (en/of dat er zelfs een nieuwere versie op de server is)

[Janoz]

Ah, dat vermoede ik al... Gewoon optie 1 dus.

Wat wel aan te raden is is om enkele cache headers mee te sturen. Gewoon de expire time ver in de toekomst zetten. Dat zijn iig 2 termen waar je middels google wel wat me kan .

[HenkS]

Janoz schreef op maandag 22 september 2008 @ 13:16:
Ah, dat vermoede ik al... Gewoon optie 1 dus.

Wat wel aan te raden is is om enkele cache headers mee te sturen. Gewoon de expire time ver in de toekomst zetten. Dat zijn iig 2 termen waar je middels google wel wat me kan .

tnx, heb net firebug toegevoegd aan mozilla, ga nu eerst kijken wat ie wel/niet ophaalt, en vervolgens ff googlen op expiretime en dan ga ik dat toevoegen

tnx voor jullie hulp

[RobIII]

Als je code post, doe dat dan voortaan aub met code tags

offtopic:
En dan zal ik maar weer eens de term SQL injection laten vallen...

[ Voor 44% gewijzigd door RobIII op 22-09-2008 13:19 ]

[Noork]

Je zou ze ook gewoon bij het aanmaken in een cache map kunnen gooien. Check b.v. of de afbeelding bestaat, en zo ja, toon dan de afbeelding vanuit de cache-map. Deze kun je b.v. periodiek leeg gooien, of nog een datum-check inbouwen. Scheelt ook weer wat db connecties.

[HenkS]

RobIII schreef op maandag 22 september 2008 @ 13:18:
Als je code post, doe dat dan voortaan aub met code tags

offtopic:
En dan zal ik maar weer eens de term SQL injection laten vallen...

excuus, ik heb het aangepast

[Kettrick]

Noork schreef op maandag 22 september 2008 @ 13:19:
Je zou ze ook gewoon bij het aanmaken in een cache map kunnen gooien. Check b.v. of de afbeelding bestaat, en zo ja, toon dan de afbeelding vanuit de cache-map. Deze kun je b.v. periodiek leeg gooien, of nog een datum-check inbouwen. Scheelt ook weer wat db connecties.

Dit ga je met name nodig hebben als je bijvoorbeeld gaat resizen e.d., maar een dergelijke setup zou ook mijn voorkeur hebben.

[Cartman!]

De code-tags of de SQL injection?

Trouwens, wat is uberhaupt je reden om images op te slaan in een database ipv. je filesystem? Dan regelt (als het goed is) je webserver zelf alle goede headers en hoef je daar geen moeite voor te doen.

[Janoz]

@lawnmower & Cartman!

Er zijn genoeg redenen te verzinnen waarom je je content in een database opslaat.


* Janoz haalt ff oude koe uit de sloot:

[PHP] plaatje uit mysql database

[Kettrick]

Cartman! schreef op maandag 22 september 2008 @ 13:37:
De code-tags of de SQL injection?

Trouwens, wat is uberhaupt je reden om images op te slaan in een database ipv. je filesystem? Dan regelt (als het goed is) je webserver zelf alle goede headers en hoef je daar geen moeite voor te doen.

Je krijgt vroeg of laat altijd sync issues tussen je db en je fs. Als ik een X aantal afbeeldingen heb bij een bepaald artikel, en ik gooi dat artikel weg, mogen die plaatjes ook gewoon weg. Dat soort dingen gaan ontzettend makkelijk in een db, dat header-geknoei neem ik dan op de koop toe

[Cartman!]

Wat dacht je van unlink() gebruiken op de bestandnamen die je wel in je tabel hebt staan? Nooit problemen mee gehad hoor

[Janoz]

Cool!! Jij hebt een filesystem dat referentiële integriteit af kan dwingen met een database?

[Noork]

Janoz schreef op maandag 22 september 2008 @ 14:18:
Cool!! Jij hebt een filesystem dat referentiële integriteit af kan dwingen met een database?

....unlink werkt in de praktijk doorgaans perfect.

[Erkens]

Janoz schreef op maandag 22 september 2008 @ 14:18:
Cool!! Jij hebt een filesystem dat referentiële integriteit af kan dwingen met een database?

Je moet ook niet handmatig in die tables gaan rotzooien, dan vraag je er ook om.
Net zoals in het door jouw aangehaalde topic staat zijn er voor beide manier genoeg voor en nadelen te vinden.

[Janoz]

Hoe denk jij met unlink referentiële integriteit af te dwingen?

@Erkens:

De enige reden dat ik dat topic aanhaal is om te laten zien dat het helemaal niet vanzelfsprekend is dat plaatjes op het filesystem moeten. Net als dat het helemaal niet vanzelfsprekend is dat het file system sneller is .

Daarnaast, met rechtstreeks kutten in een database voorkomt een fatsoenlijke database ook dat je plaatjes niet weggegooid worden* (of hebben ze bij MySQL nu ook al foreign key constraints geïmplementeerd)

*Uitgaande van bv een N:M koppeling tussen plaatjes en artikelen. Plaatjes kunnen alleen weggegooid worden wanneer er geen referenties in de koppeltabel staan.

[ Voor 69% gewijzigd door Janoz op 22-09-2008 14:31 ]

[HenkS]

hallo

ik heb firebug erop gezet en in mijn eerder geplaatste code, heb ik boven de bestaande header het volgende geplaatst:

PHP:

Header("Expires: Sat, 26 Jul 2014 05:00:00 GMT"); // Date in the future

echter zie ik dat er nog steeds niks uit de cache wordt gehaald

firebug zegt: 45kb uit cache (van de hele pagina)

en bij de response kopteksten van firebug staat bij het plaatje:
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache

hoe kan dat?

[Erkens]

Janoz schreef op maandag 22 september 2008 @ 14:26:
De enige reden dat ik dat topic aanhaal is om te laten zien dat het helemaal niet vanzelfsprekend is dat plaatjes op het filesystem moeten. Net als dat het helemaal niet vanzelfsprekend is dat het file system sneller is .

Uiteraard, immers een database wil nog wel eens een grotere cache hebben waardoor veel opgehaalde data rechtstreeks uit het geheugen kunnen komen (keerzijde is wel dat je cache met nutteloze troep zoals dergelijke plaattjes kan komen te staan).

HenkS schreef op maandag 22 september 2008 @ 14:28:

en bij de response kopteksten van firebug staat bij het plaatje:
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache

hoe kan dat?

Wat denk je? Je kan toch ook die headers sturen (alleen dan natuurlijk zodat je _wel_ cached).

[HenkS]

ik heb dit toegevoegd boven de headers:

Header("Cache-Control: max-age=3600, must-revalidate");

dit zou toch voldoende moeten zijn om de cache aan te zetten? echter blijft het resultaat hetzelfde

[Janoz]

Weet je waarom je die 'must-revalidate' er bij hebt staan en wat dat betekent?

[Cartman!]

Janoz: als je wijzigingen uitvoer op je database dan kun je in datzelfde script toch simpel de afbeeldingen updaten/deleten. Ik vind het enorm k*t werken met images in een database omdat t vaak alleen maar problemen oplevert (via het filesystem was dit topic er niet geweest). Ik sla altijd gewoon het pad op naar de image, werkt imo veel efficienter en flexibeler. Want als je bijv. voor elke image 10 anderen moet genereren (resizen, croppen..noem maar op), ga je die dan ook allemaal in je database zetten? Ik vind het niet handig.

[HenkS]

Janoz schreef op maandag 22 september 2008 @ 15:11:
Weet je waarom je die 'must-revalidate' er bij hebt staan en wat dat betekent?

nee , maar ik kom er echt niet uit, e.e.a. opgezocht van cache-header oa dit erin geplaatst:
Header("Cache-Control: max-age=3600");

en toch is de response no-cache?

[Janoz]

Cartman! schreef op maandag 22 september 2008 @ 15:11:
Janoz: als je wijzigingen uitvoer op je database dan kun je in datzelfde script toch simpel de afbeeldingen updaten/deleten.

Kan, maar de werking daarvan is lastiger te garanderen.

Ik vind het enorm k*t werken met images in een database omdat t vaak alleen maar problemen oplevert (via het filesystem was dit topic er niet geweest).

Dit topic was er dan ook geweest. Het gaat hier over de caching tussen server en client. Of het plaatje op de server nu van het filesystem, uit een database, van een webcam of ter plekke ingescand wordt is niet relevant.

Ik sla altijd gewoon het pad op naar de image, werkt imo veel efficienter en flexibeler.

Efficienter misschien, maar waarom flexibeler?

Want als je bijv. voor elke image 10 anderen moet genereren (resizen, croppen..noem maar op), ga je die dan ook allemaal in je database zetten? Ik vind het niet handig.

Of je je bewerkte data nu wegschrijft met een stuk diskwrite code, of een insert naar de database maakt natuurlijk weinig uit. Desnoods zet je het in een apparte functie. Dan maakt het al helemaal niet meer uit of je nu 1, 2 of 10 plaatjes moet saven.

Tot slot, ik zeg nergens dat je het in een DB moet zetten. Ik zeg alleen dat een DB helemaal niet fout is. Het is vooral een reactie op de opmerking 'dat plaatjes niet in een database horen' opmerking. Dat is nu eenmaal niet zo vanzelfsprekend.

Goed, qua efficientie is de kans groot dat de filesysteem oplossing de beste is, maar op het gebied van onderhoudbaarheid en integriteit wint de database oplossing het.

[Soultaker]

Naast cache control parameters meegeven, kun je ook support voor wijzigingen inbouwen door de If-Modified-Since en If-None-Match headers te parsen en af te handelen. Daarvoor moet de client weliswaar opnieuw een request doen, maar hoef je geen data over te sturen als de gegevens niet veranderd zijn. Als je je plaatjes gewoon als bestanden opslaat krijg je die functionaliteit cadeau omdat de webserver gewoon de wijzigingsdatum van het filesystem gebruikt.

[Cartman!]

Ik vind het flexibeler omdat ik zonder tussenkomst van code gewoon een plaatje kan bekijken die ik download via ftp of via een image manager. Met je database is dat (zover ik weet) niet mogelijk zonder tussenkomst van scripting.

Zelfde voor onderhoudbaarheid, als je ergens afbeeldingen moet wijzigen is het toch veel makkelijker om even een map open te trekken en de afbeeldingen te wijzigen?

Dat images in een database perse fout is wil ik niet zeggen, ik vind het alleen een stuk omslachtiger dan via je filesystem. Je webserver regelt netjes alle headers voor je als je alles via je filesystem doet.

Waarom is volgens jou dan een database met images beter qua onderhoud en integriteit? Je database is in feite ook gewoon maar een bestand op je disk, kan net zo goed corrupt raken, ben je denk ik verder van huis dan als een paar afbeeldingen maar corrupt raken.

Interessante discussie imo

[curry684]

RobIII schreef op maandag 22 september 2008 @ 12:13:
Je zit qua caching wel goed inderdaad, maar waarom zou je statische content (die dan weliswaar uit de DB komt) 'nogmaals' willen cachen? Cachen (server-side) heeft enkel nut bij dynamische content waarvoor je bij iedere pageview weer je resources flink belast. Het ophalen van een image uit de DB of van een schijf valt daar nou niet echt onder (aangenomen dat je DB verder wel fatsoenlijk in elkaar steekt). Iedere image afzonderlijk kun je zien als statische content (en dus boeie in welke volgorde die staan). Het is de uitgespuugde gegenereerde content die het cachen (misschien) waard kan zijn.

Afhankelijk van de situatie is het helemaal niet zo stom om semi-statische data in het filesystem te cachen hoor? Hoewel met name in distributed situaties waarbij web- en DB-server niet dezelfde zijn is het ook bij klassieke same-server setups vaak een simpele mogelijkheid om de load op de database te verlagen, wat toch snel de eerste bottleneck is bij sites die een beetje druk bezocht worden.

[RobIII]

curry684 schreef op maandag 22 september 2008 @ 16:56:
[...]

Afhankelijk van de situatie is het helemaal niet zo stom om semi-statische data in het filesystem te cachen hoor?

Mja, maar daar zou je dan vooraf al voor gekozen hebben om de images niet in de DB te zetten

curry684 schreef op maandag 22 september 2008 @ 16:56:
Hoewel met name in distributed situaties waarbij web- en DB-server niet dezelfde zijn

Nee, maar dat is het bij een "losse image-server" (waarbij de images wel door de web-server geserveerd worden en dus niet via een eigen ip/url etc.) ook niet. Ik ga wel uit van gelijke situaties.

curry684 schreef op maandag 22 september 2008 @ 16:56:
is het ook bij klassieke same-server setups vaak een simpele mogelijkheid om de load op de database te verlagen, wat toch snel de eerste bottleneck is bij sites die een beetje druk bezocht worden.

De overhead van een image uit de DB t.o.v. uit het filesystem halen is zeker aanwezig, maar of die dusdanig veel is dat je het daar moet gaan zoeken op het moment dat je tegen bottlenecks aan loopt... kweet niet. Ikzelf sla zelden tot nooit blobs in een DB op dus ik heb daar niet echt 'feel' voor in dit geval.

Punt blijft dat de bottleneck in dit geval überhaupt niet zit in het server-side cachen maar in het client-side cachen dat niet/verkeerd wordt gedaan.

[ Voor 17% gewijzigd door RobIII op 22-09-2008 17:12 ]

[Janoz]

Cartman! schreef op maandag 22 september 2008 @ 16:21:
Ik vind het flexibeler omdat ik zonder tussenkomst van code gewoon een plaatje kan bekijken die ik download via ftp of via een image manager. Met je database is dat (zover ik weet) niet mogelijk zonder tussenkomst van scripting.

Zelfde voor onderhoudbaarheid, als je ergens afbeeldingen moet wijzigen is het toch veel makkelijker om even een map open te trekken en de afbeeldingen te wijzigen?

Hierin zit ook meteen het gevaar. Dat je er zo makkelijk bij kunt betekent ook dat je makkelijk schade aan kunt richten. Per ongeluk wat weggooien of verkeerde plaatje hernoemen oid.

Bij een kleine hobbysite is het misschien nog wel te overzien, maar een behoorlijke gallery site is al een stuk lastiger.

Dat images in een database perse fout is wil ik niet zeggen, ik vind het alleen een stuk omslachtiger dan via je filesystem. Je webserver regelt netjes alle headers voor je als je alles via je filesystem doet.

De webserver regelt het alleen wanneer je je plaatjes ook rechtstreeks naar de gebruiker stuurt zonder tussenkomst van wat dan ook. Bij content is het echter nog wel eens zo dat je ook wat autorisatie toe wilt voegen, of andere dynamische functionaliteit. Op dat moment kun je het niet meer enkel aan de webserver overlaten en is dat voordeel ook al weg.

Waarom is volgens jou dan een database met images beter qua onderhoud en integriteit? Je database is in feite ook gewoon maar een bestand op je disk, kan net zo goed corrupt raken, ben je denk ik verder van huis dan als een paar afbeeldingen maar corrupt raken.

Als je db corrupt raakt maakt het niet uit of je je plaatjes er wel of niet in had. Jij zou ook je meta data kwijt zijn waardoor je map met plaatjes niks meer is dan een hoop ongestructureerde afbeeldingen (plat gezegd)

Alles kan corrupt, daarom maken we backups. Als je al je content bij elkaar hebt dan is het draaien van een backup heel straight forward. Zou je je plaatjes op de schijf hebben dan zul je 2 backups moeten maken. 1 van de DB en 1 van de map met daarin die plaatjes. Niet alleen is dit omslachtiger, maar de kans dat je backups out of sync zijn is groot omdat er geen integriteit afgedwongen (kan) worden. Het kan best zijn dat een gebruiker een plaatje upload tijdens je backup sessie. Afhankelijk van de volgorde kan het dan zijn dat er wel een verwijzing in de DB-backup staat terwijl er niks in de file-backup staat of vice versa.

Als je het puur theoretisch bekijkt zou de borging van je applicatie als volgt moeten zijn:

Code - > Versie beheer systeem
Vormgeving (+ statische content) -> Versie beheer systeem
Content -> Database + backups database


En integriteit, dat is waar een database om draait. Die kan garanderen dat een plaatje aanwezig is wanneer je er een koppeling naar hebt. Foreign key constraints verbieden je om een plaatje te verwijderen dat nog in gebruik is. Dit soort dingen zijn niet af te dwingen wanneer een beheerder gewoon 'een map open kan trekken'.

[curry684]

RobIII schreef op maandag 22 september 2008 @ 17:03:
[...]

Mja, maar daar zou je dan vooraf al voor gekozen hebben om de images niet in de DB te zetten

Nou ik heb toch echt wel een systeem gebouwd voor een klant waarbij ruim 2GB aan plaatjes in de DB staat. Met als hoofdredenen de complexe achterliggende koppelingen en de voorbereiding om ooit distributed te kunnen draaien.

De overhead van een image uit de DB t.o.v. uit het filesystem halen is zeker aanwezig, maar of die dusdanig veel is dat je het daar moet gaan zoeken op het moment dat je tegen bottlenecks aan loopt... kweet niet. Ikzelf sla zelden tot nooit blobs in een DB op dus ik heb daar niet echt 'feel' voor in dit geval.

Op het moment dat de database een bottleneck wordt is het niet zelden een gevalletje te langdurige lock contention door overdadige filesystem I/O - aan de lopende band grote lappen data uit je DB fetchen helpt daar niet bij. En dan is er dus wel degelijk een aanmerkelijk voordeel bij te halen om die I/O beperkt houdbaar over te hevelen naar een non-locking belasting van liefst ook nog een ander filesystem.

Punt blijft dat de bottleneck in dit geval überhaupt niet zit in het server-side cachen maar in het client-side cachen dat niet/verkeerd wordt gedaan.

Ik beantwoordde enkel je vraag over waarom je uberhaupt DB-based static content zou willen cachen

[Cartman!]

Janoz, ik snap je punt en je hebt een duidelijk verhaal neer weten te zetten, bedankt

Misschien dat we toch een ander soort applicaties maken dan want nog steeds zou ik het niet handig vinden om het toe te passen in mn werk. Als een site ineens explosief groot wordt kun je met filesysteem heel makkelijk gebruik maken van een CDN met een lichte webserver die enkel images host bijv, dat lukt je niet met een database (zo doet Netlog het bijv ook). Dat lijkt mij toch meer portable dan via databases.

Een volgende keer als er hier een discussie is over wat we moeten doen zal ik je verhaal zeker meenemen

[HenkS]

om nu toch nog even terug te komen naar waarom ik het topic starte (al is de discussie eromheen erg interessant)

ik heb nu even wat zaken opgenomen in mijn code ter test:

PHP:

// calc an offset of 24 hours
$offset = 3600 * 24;    
// calc the string in GMT not localtime and add the offset
$expire = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
//output the HTTP header
$time = time() - 60; // or filemtime($fn), etc
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $time).' GMT');
Header("Cache-Control: max-age=36000");
Header($expire);

nu heb ik 3 headers opgenomen zoals jullie zien

// de 1e is een last modified, volgens mij heeft dat geen zin met mijn opzet, dus zou ik die weg kunnen doen, aangezien het puur om de plaatjes gaat en niet om de overige dynamische content

// de 2e header met cache-control is de tijd dat er gecached moet worden, dit is volgen mij zeker nodig en zou ik nog op veel langer kunnen zetten aangezien de plaatjes nooit veranderen
// de 3e is een datum in de toekomst (zou ik nog verder in de toekomst kunnen zetten, maar voor de test moet dit wel goed zijn

echter als ik dit zo in de code plaats, dan is volgens firebug nog niks gecached van de images, hoe kan dat?

[CodeCaster]

Omdat je plaatje volgens die code altijd een minuut geleden is bewerkt?

[HenkS]

CodeCaster schreef op dinsdag 23 september 2008 @ 09:59:
Omdat je plaatje volgens die code altijd een minuut geleden is bewerkt?

moet die datum dan verder in het verleden liggen of in de toekomst? ik begrijp het even niet meer. ik heb overigens beide geprobeerd zonder succes

[HenkS]

even wat info uit firebug:

Last-Modified Tue, 23 Sep 2008 09:22:05 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires Thu, 19 Nov 1981 08:52:00 GMT
Pragma no-cache
Keep-Alive timeout=5, max=100

wat ik niet begrijp:

die cach-control zegt: no-cache hoe komt dat

de expire date? hoe kan dat in vredesnaam 1981 zijn?

[YakuzA]

Ik neem aan dat de browser checkt wat de last modified datum is, als deze niet overeenkomt met wat hij in zijn cache heeft staan, haalt je browser opnieuw het plaatje op.

In je headers veranderd continu de Last modified datum, dus zal de browser sowiezo elke keer het plaatje opnieuw opvragen nu.

[HenkS]

ik heb nu het volgende

waarbij de expire date als ik deze afdruk in de code het volgende is:
Expires: Fri, 03 Oct 2008 08:44:27 GMT

PHP:

// calc an offset of 24 hours
$offset = 36000 * 24;   
// calc the string in GMT not localtime and add the offset
$expire = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
//output the HTTP header
Header($expire);
Header("Cache-Control: max-age=36000");

echter verandert de response van firebug helemaal niet/nergens?

[Voutloos]

time() + X is uiteraard elke seconde anders.

[HenkS]

Voutloos schreef op dinsdag 23 september 2008 @ 10:54:
time() + X is uiteraard elke seconde anders.

oeps ja! maar goed los daarvan....

als ik bovenstaande code in de header van iedere pagina zet

dan is de expire time wel echt wat ik meegeef volgens firebug, op pagina niveau dan. dus 3 oktober 2008 zoals ik hem ook echo op de pagina.

echter als ik met firebug op image niveau kijk (dus plaatje.php) dan is de expire date 1981 en niet zoals op pagina niveau op oktober 3 2008

hoe kan dat?

[Erkens]

Installeer eens de "Live HTTP headers"-addon in firefox, hiermee kan je beter zien welke headers er verstuurd worden.

[HenkS]

tnx, heb t eens gedaan

op iedere pagina heb ik deze headers:

HTTP/1.x 200 OK
Date: Tue, 23 Sep 2008 09:18:09 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8h mod_autoindex_color PHP/5.2.6
X-Powered-By: PHP/5.2.6
Expires: Wed, 01 Jan 2014 00:00:00 GMT
Cache-Control: max-age=36000
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Dit lijkt me toch goed?

echter op plaatje niveau (dus plaatje.php onderdeel van een pagina krijg ik dit terug)
GET /xampp/fifaworld360/plaatje.php?plaatje_id=47 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/xampp/fifaworld360/index.php?page=league
Cookie: PHPSESSID=ed5f88c755e62506abb6cb5148901835
Authorization: Basic cm9vdDpzY2hhcm4wMQ==
Cache-Control: max-age=0

vind ik toch wel vreemd

[Erkens]

ehm, je post van het plaatje nu de headers die je verstuurd niet die je ontvangt (die komen daarna)

[Voutloos]

Oftewel zet er aub altijd duidelijk Request Headers of Response Headers bij.
Het is adhv bepaalde headers wel af te leiden, maar als jet het er duidelijk bij zet weet je toch een stuk beter waar je mee bezig bent en het leest voor ons ook wat makkelijler.

(en imo kan je beter toch nog maar een keertje een http caching tutorial erbij pakken ipv elke 5 minuten hier een post maken )

[ Voor 20% gewijzigd door Voutloos op 23-09-2008 11:27 ]

[CodeCaster]

Waarom ga je nou zelf eens niet kijken wat er gebeurt? Je vangt nu niks af in je code, maar gooit iedere keer het plaatje eruit.

Te ondernemen stappen:

• vraag de headers op die de browser stuurde
• kijk naar de if-modified-since header
• als deze overeenkomt met de datum van jouw plaatje stuur je de header voor "not modified" en verbreek je de verbinding
• komt deze niet overeen, of ontbreekt de header, dan stuur je het hele plaatje met de juiste headers

Dit lijkt me toch goed?
(...)
vind ik toch wel vreemd

Ja heel leuk dat het jou goed lijkt en heel vervelend dat je het vreemd vindt, maar zoek nou zelf eens op hoe HTTP werkt en kijk welke headers je moet sturen om de browser te laten cachen, en geen overbodige data over de lijn te sturen..

[ Voor 27% gewijzigd door CodeCaster op 23-09-2008 11:34 ]

[HenkS]

excuus, kom er gewoon niet zo goed uit, ga me nog eens verdiepen

voor de geinteresseerden, het gaat om deze pagina:

http://www.fifa-gaming.com/index.php?page=league

[HenkS]

ik ben al wat verder

ik heb ff alles verwijderd mbt headers etc en ik ben dit artikel gaan lezen:

http://www.sitepoint.com/article/caching-php-performance/2/

waarbij ik de $lastModified vul met de datum van de laatst gespeelde wedstreijd van desbetreffende competitie.

echter als ik dit nu allemaal doe en ik doe op een gegeven moment:
$request = getallheaders();
print_r($request);

echter is deze waarde altijd 0:
$request['If-Modified-Since'];

terwijl je deze waarde wel moet hebben als je volgens het artikel php 4.3.0 of hoger hebt met apache (ik heb php 5.x en apache).

Hoe kan het zijn dat deze waarde dus 0 is?

[r0bert]

http://nl3.php.net/getallheaders

Fetches all HTTP headers from the current request.

Note: "request"

Edit:
Sla bij je image gewoon een 'legale' timestamp op, zodat wanneer de image werkelijk gewijzigd is deze ook inderdaad vernieuwd wordt. Die timestamp kun je vervolgens inzetten als Modified date. Correct, functioneel en werkend volgens mij.

Evt. met een MySQL trigger/handler die 'AFTER-UPDATE' je datum veranderd, heb je er ook nog eens geen omkijken naar.

[ Voor 61% gewijzigd door r0bert op 24-09-2008 08:23 ]

[Voutloos]

HenkS schreef op dinsdag 23 september 2008 @ 13:46:
echter als ik dit nu allemaal doe en ik doe op een gegeven moment:
$request = getallheaders();
print_r($request);

echter is deze waarde altijd 0:
$request['If-Modified-Since'];

'Op een gegeven moment' Ik hoop dat je de volgende hit op _dezelfde_ url bedoeld?