[http] images uit DB, hoe te cachen?

[BasieP]

Beste mensen, ik heb een situatie waarin ik afbeeldingen uit de database haal, en moet serveren als 'statische' content.

De afbeeldingen wijzigen nooit, maar kunnen wel verwijderd worden. o.a. om ref. integriteit af te dwingen staan ze in een DB.

Ik heb nu de volgende php file om mijn afbeelding te serveren:

PHP:

$id    = mysql_real_escape_string($_GET['id']);
$query = "SELECT *, UNIX_TIMESTAMP(timestamp) as ticks FROM `" . $ucms_cfg['prefix'] . "image_image` WHERE id = '$id'";

$row = mysql_fetch_object(mysql_query($query));

$ar = getHeaders(); //deze haalt de request headers op;

if (isset($ar['If-Modified-Since']) && // If-Modified-Since should exists
    $ar['If-Modified-Since'] != '' && // not empty
    strtotime($ar['If-Modified-Since']) >= $row->ticks) // and greater than
{
    // Sending 304 response to browser
    // "Browser, your cached version of image is OK
    // we're not sending anything new to you"
    header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $row->ticks) . ' GMT', true, 304);

    exit();
}

header('Cache-Control: public');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $row->ticks) . ' GMT', true, 200);
header('Expires: ' . gmdate('D, d M Y H:i:s', $row->ticks + 86400*365) . ' GMT', true, 200);
header("Content-length: ".strlen($row->image));
header("Content-type: $row->type");

switch ($row->type)
{
    case "image/gif": header("Content-disposition: inline; filename=image.gif"); break;
    case "image/jpeg": header("Content-disposition: inline; filename=image.jpg"); break;
    case "image/png": header("Content-disposition: inline; filename=image.png"); break;
}

echo $row->image;

de headers die ik in firebug terug zie zijn de volgende

code:

Response Headers
Date    Fri, 15 Apr 2011 13:58:31 GMT
Server  Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.7a mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4 Perl/v5.8.8
X-Powered-By    PHP/5.2.13
Pragma  no-cache
Cache-Control   public
Expires Sat, 14 Apr 2012 12:04:26 GMT
Content-Disposition inline; filename=image.jpg
Last-Modified   Fri, 15 Apr 2011 12:04:26 GMT
Content-Length  26880
Keep-Alive  timeout=5, max=99
Connection  Keep-Alive
Content-Type    image/jpeg

Request Headers
User-Agent  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  115
Connection  keep-alive

ik heb dit topic gelezen, maar dit beantwoord niet helemaal mijn vragen:
php en image caching


Wat ik dus nu doe is netjes een 304 sturen als ik de if-modified-since krijg (maar die krijg ik volgens mij nooit)

verder heb ik een last modified en expires date opgegeven. Mijn last modified komt ook uit de DB, en die is dus elke keer hetzelfde, en ligt in het verleden.
De expires ligt in de toekomst.

Toch blijft mijn firefox requests naar de server sturen, en haalt niks uit de cache...
wat doe ik fout?

gooit die pragma header roet in het eten? die komt uit firefox.. waarom staat daar no-cache?

[matthijsln]

BasieP schreef op vrijdag 15 april 2011 @ 16:07:
Toch blijft mijn firefox requests naar de server sturen, en haalt niks uit de cache...
wat doe ik fout?

gooit die pragma header roet in het eten? die komt uit firefox.. waarom staat daar no-cache?

Ja, die pragma header is de oorzaak. Die komt niet van firefox, hij staat bij response headers dus komt van apache/php.

[ZpAz]

Zoals ik het nu zie lijkt het alsof de plaatjes daadwerkelijk in de database staan? Het is beter om de verwijzingen naar plaatjes in de database op te slaan in plaats van het plaatje zelf.

[Compuhair]

Er zijn prima redenen om plaatjes of bestanden in een database op te slaan. Het is niet correct om te zeggen dat het altijd een beter idee is om alleen een referentie naar het bestand op te slaan in de database.

[orf]

Laat je functie getHeaders() eens zien? Gebruik je daarnaast sessions? Dat zou de pragma kunnen veroorzaken. Je kunt 'm zelf overschrijven, maar het is interessant om te kijken waar die vandaan komt.

[NMe]

PHP:

header('Pragma: public', true);

Zou het moeten oplossen. Symptoombestrijding, maar als je niet kan vinden waar 'ie vandaan komt los je zo in elk geval je directe probleem op.

[ Voor 46% gewijzigd door NMe op 15-04-2011 21:48 ]

[ReenL]

PS: Bedenk wel dat je bij elke cache nu wel de image uit de db trekt. Als je database server los is van je webserver bespaar je op je server netwerk niets, enkel naar de gebruiker toe spaar je bandbreedte uit.

* ReenL mompelt ook nog iets over blobs in aparte tabellen, foutafhandeling en E-Tags.

[matthijsln]

ReenL schreef op zaterdag 16 april 2011 @ 14:49:
PS: Bedenk wel dat je bij elke cache nu wel de image uit de db trekt. Als je database server los is van je webserver bespaar je op je server netwerk niets, enkel naar de gebruiker toe spaar je bandbreedte uit.

Het uitsparen van bandbreedte (requests) naar de gebruiker is het hele punt, daardoor laadt je pagina sneller en wordt je serverload verlicht.

Echt, databases zijn niet speciaal trager gemaakt dan filesystems om bitjes op te halen. Ze zijn wel trager, maar het is niet een algemene stelregel dat je niet een boel bits erin op mag slaan.

[P_de_B]

ZpAz schreef op vrijdag 15 april 2011 @ 18:47:
Zoals ik het nu zie lijkt het alsof de plaatjes daadwerkelijk in de database staan? Het is beter om de verwijzingen naar plaatjes in de database op te slaan in plaats van het plaatje zelf.

Ja, in 2001 was dat misschien zo. Moderne databases hebben daar geen problemen meer mee. Je hebt daarnaast aanvullende functionaliteit tot je beschikking als je ze wel in de db stopt (referentiële integriteit, eenvoudige backup, eenvoudiger controleren van rechten).

[leuk_he]

matthijsln schreef op zaterdag 16 april 2011 @ 15:22:
[...]

wordt je serverload verlicht.

Die net niet. Maar of die echt van belang is....

[matthijsln]

leuk_he schreef op zaterdag 16 april 2011 @ 15:54:
[...]
Die net niet. Maar of die echt van belang is....

Jawel... Als een browser een plaatje gecached heeft doet ie geen request. Een request zorgt ervoor dat de server werk moet verrichten (load).

[Verwijderd]

Zet er een caching proxy tussen, bijvoorbeeld Varnish of Squid. Dan kun je die proxy al afdwingen afbeeldingen te cachen en ben je niet afhankelijk van instellingen op de client. De proxy kan ook die headers toevoegen.

[matthijsln]

Dat soort dingen hebben hun plaats, maar pas doen nadat je applicatie gewoon de http caching headers goed zet...

[Verwijderd]

matthijsln schreef op zaterdag 16 april 2011 @ 17:07:
Dat soort dingen hebben hun plaats, maar pas doen nadat je applicatie gewoon de http caching headers goed zet...

In dit geval hoeft het niet omdat de afbeeldingen niet wijzigen. Als een afbeelding ten onrechte nog een uurtje of een dag in de cache zit dan is dat vast niet erg.

[matthijsln]

Verwijderd schreef op zaterdag 16 april 2011 @ 17:10:
[...]
In dit geval hoeft het niet omdat de afbeeldingen niet wijzigen. Als een afbeelding ten onrechte nog een uurtje of een dag in de cache zit dan is dat vast niet erg.

In dit geval niet nee. In veel andere toepassingen misschien wel. Het goed zetten van de headers is niet zo moeilijk. Nou zal een proxy server instellen dat ook niet zijn, maar het maakt je serverconfiguratie wel complexer.

[ReenL]

Het uitsparen van bandbreedte (requests) naar de gebruiker is het hele punt, daardoor laadt je pagina sneller

eensch

en wordt je serverload verlicht.

Oneens, je load is hetzelfde misschien een heeeeeeeel klein beetje lager, je gebruikt even veel geheugen en alleen je bandbreedte is lager.

Echt, databases zijn niet speciaal trager gemaakt dan filesystems om bitjes op te halen. Ze zijn wel trager, maar het is niet een algemene stelregel dat je niet een boel bits erin op mag slaan.

Wie had het over het filesystem? Ik niet.

Ik wilde zeggen dat je methode alleen bandbreedte bespaart omdat je dit doet:

code:

- Haal het plaatje op;
- Controleer de datum (met strtotime);
- Kom erachter dat het plaatje niet nodig is en stuur een header terug.
of
- Stuur het plaatje naar de gebruiker

Daarbij is strtotime best een zware functie en heb je dus altijd het hele plaatje van je database moeten trekken.

Dit is mijn idee van cachen:

code:

- Haal metadata op;
- Controleer eerst op e-tag (als die niet beschikbaar is pas het zware strtotime gebruiken);
- Kom erachter dat het plaatje niet nodig is en stuur een header;
Of
- Haal het plaatje op en stuur het naar de gebruiker.

Of je dit met het filesystem of in je database doet moet je zelf maar uit zoeken. Waar het om gaat is dat mijn methode naast bandbreedte ook serverload vermindert wanneer de client eenmaal een cache heeft.

[Gomez12]

@ReenL : Slaat Mysql nog steeds niet zijn blobs zelf los op? Ik dacht dat hier sprake van was dat ze dit zouden implementeren zodat het plaatje enkel opgehaald zou worden als je ook echt die kolom in je query gebruikt...

Als ze dit namelijk al geimplementeerd hebben (ik kan het zo snel even niet vinden) dan haal je al enkel de metadata op...

[ReenL]

@Gomez:
Punt is dat het geselecteerd wordt (door de *). In PHP kan je niet een resource selecteren en alleen de pointer in het geheugen houden. Je hebt gewoon een gevuld stdClass met fetch_object. Dus het maakt niet zoveel uit hoe MySQL intern werkt, in elk geval voor de mysql_* functies.

[mrFoce]

ReenL schreef op zaterdag 16 april 2011 @ 19:59:
Oneens, je load is hetzelfde misschien een heeeeeeeel klein beetje lager, je gebruikt even veel geheugen en alleen je bandbreedte is lager.

offtopic:
Volgens mij is jouw denkwijze heel simpel. Jij ziet waarschijnlijk 100 requests in totaal. Ja, dan is de load marginaal. Wat nou als de TS een website heeft met 1 miljoen requests per dag. Verder is jouw kennis volgens mij een beetje klok/klepel en begrijp je niet helemaal wat de webserver precies doet. Elk plaatje dat je 'served' moet de webserver namelijk 'serveren', er zijn dan limitaties (aantal connecties) e.d. die gaan meetellen en server load / geheugen gebruik etc. Als de server 1 plaatje moet doorgeven, betekend dat dus dat 1 connectie nodig is. Geen probleem, maar als je 1 miljoen requests of meer hebt dan is elke connectie die je uit kan sparen, er 1. Verder spreek je jezelf al tegen met 'heel klein beetje lager'.

[Voutloos]

@ReenL en mrForce: De verbinding is er al, maar als je niet een heel plaatje uitstuurt ben je een stuk eerder klaar.

Overigens kan het wel iets efficienter: stop de check voor de modified since in de query. Geen row == direct klaar.

[mrFoce]

Voutloos schreef op zaterdag 16 april 2011 @ 23:17:
@ReenL en mrForce: De verbinding is er al, maar als je niet een heel plaatje uitstuurt ben je een stuk eerder klaar.

Overigens kan het wel iets efficienter: stop de check voor de modified since in de query. Geen row == direct klaar.

offtopic:
Uiteraard, maar als die gelijk wordt afgesloten doordat de 'request' afgehandeld is, kan deze gelijk weer gebruik worden voor een andere request. Misschien had ik dat beter moeten verwoorden

[Gomez12]

mrFoce schreef op zondag 17 april 2011 @ 00:01:
[...]

offtopic:
Uiteraard, maar als die gelijk wordt afgesloten doordat de 'request' afgehandeld is, kan deze gelijk weer gebruik worden voor een andere request. Misschien had ik dat beter moeten verwoorden

offtopic:
Met 1 miljoen requests per dag wil je je echt niet hier druk over gaan maken.
Je hebt het of anders opgelost (ergens anders gecached) of je gebruikt iets als een connection pool of je interesseert je er gewoon niet voor.
Over dit soort dingen gaan nadenken zonder een structurele oplossing te pakken is gewoon verkeerd handelen

[ReenL]

Geen probleem, maar als je 1 miljoen requests of meer hebt dan is elke connectie die je uit kan sparen, er 1.

Precies mijn punt, hij spaart aan de front-end (http), en niet aan de back-end (php to mysql). Daar waarschuw ik de TS voor, door te zeggen dat hij het plaatje nu _altijd_ in memory heeft en over een socket moet sturen (tussen php-mysql), ongeacht of hij hem nodig heeft of niet. Ik zeg niet dat een tweede connectie nodig is en ook niet dat het met files moet.

Maar er zit een breekpunt ik kan met zekerheid zeggen dat als je 90% van je pagina's alleen maar headers hoeft te sturen dat het efficiënter is om in de eerste instantie de blob niet mee te selecteren. In realiteit ligt dit breekpunt een stuk lager.

[BasieP]

bedankt mensen had niet zoveel reacties verwacht.
Ik heb inderdaad gekozen voor plaatjes in DB vanwege ref. integriteit. Verder scheelt het ook een hoop code (waarin weer fouten kunnen komen)
Ik heb helaas niet de mogelijkheid voor een proxy, aangezien het verhaal gewoon bij een webhoster draait. Dan zou de site opeens een beetje duurder worden.

[BasieP]

sorry voor de schop, maar ik kom er toch niet uit.

Zowel firefox als chrome versturen gewoon geen If-Modified-Since header bij hun requests naar mijn plaatjes..
wtf doe ik fout?

ik heb even gekeken naar de GA.js (van google analytics)
en dat gaat zo:

initiele load response headers:

code:

Age:36885
Cache-Control:max-age=86400, public
Content-Encoding:gzip
Content-Length:11581
Content-Type:text/javascript
Date:Thu, 28 Apr 2011 22:41:22 GMT
Expires:Fri, 29 Apr 2011 22:41:22 GMT
Last-Modified:Tue, 19 Apr 2011 17:52:10 GMT
Server:GFE/2.0
Vary:Accept-Encoding
X-Content-Type-Options:nosniff

daarna een willekeurige load request:

code:

Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en,nl-NL;q=0.8,nl;q=0.6,en-US;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Host:www.google-analytics.com
If-Modified-Since:Tue, 19 Apr 2011 17:52:10 GMT
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16

en responds:

code:

Age:36723
Date:Thu, 28 Apr 2011 22:41:22 GMT
Expires:Fri, 29 Apr 2011 22:41:22 GMT
Server:GFE/2.0

(en dan dus status 304)

Nu heb ik ook een 'last-modified' en een 'expires' header, en nu sinds kort ook een 'date' header, maar blijkbaar is dat niet genoeg voor de browser om een if-modified-since te sturen...

sterker nog. Als ik via google crome mijn pagina analyseer (audit), dan zegt hij zelfs dat ik expliciet geen caching gebruik..

[Spider.007]

Ik zou mijn afbeeldingen door Cacheability Query halen. Grote kans dat je het zo wel krijgt opgelost

[kwaakvaak_v2]

Dan moet de maker van dat script eerst even wat oplossen

code:

/disk2/server/httpd/cgi-bin/spider.py:288: DeprecationWarning: raising a string exception is deprecated raise Error, http_status_codes.get(errcode, errmsg)

[Soultaker]

ReenL schreef op zaterdag 16 april 2011 @ 19:59:
Daarbij is strtotime best een zware functie en heb je dus altijd het hele plaatje van je database moeten trekken.

Wat betreft de database heb je een punt (het zou beter zijn eerst alleen de tijd op te halen, en de image data alleen als je 'm nodig hebt) maar dat strtotime() een zware functie zou zijn is onzin. Er gebeurt zó veel voor het afhandelen van een HTTP-request dat één call naar strtotime() meer of minder niet veel uit maakt.

Als ik lokaal test met:

time php -r 'for ($i = 0; $i < 1000000; ++$i) strtotime("Sat, 14 Apr 2012 12:04:26 GMT");'

Dan kom ik op nog geen 12 microseconden per call, en dat is op een vrij oude processor.

[BasieP]

zie hier screenshotje van wat chrome doet.



Ik draai dus een crossfade scriptje die dmv javascript telkens de backgroundimage van een div aanpast. je ziet hier dus over tijd telkens een request naar een random plaatje.
Echter heb ik in totaal 6 plaatjes ofzo, en zou hij dus inmiddels al lang alles uit zijn cache moeten halen...

Als ik de afbeelding direct in de html duw doet ie het wel

[Voutloos]

Je kan er sowieso een sprite van maken.

[BasieP]

kidding right?

[matthijsln]

edit: onzin

[ Voor 98% gewijzigd door matthijsln op 29-04-2011 16:15 ]

[Voutloos]

Ja, was geen goed idee van mij. Of sowieso iets dat je pas kan doen als je caching goed zit.

Trouwens, tenzij 'toevallig' opgelost zodra je caching gefixed hebt: 6s voor 1 request om 100KB is uberhaupt niet acceptabel.

[ Voor 31% gewijzigd door Voutloos op 29-04-2011 16:17 ]

[Gomez12]

BasieP schreef op vrijdag 29 april 2011 @ 16:02:
zie hier screenshotje van wat chrome doet.

[afbeelding]

Ik draai dus een crossfade scriptje die dmv javascript telkens de backgroundimage van een div aanpast. je ziet hier dus over tijd telkens een request naar een random plaatje.
Echter heb ik in totaal 6 plaatjes ofzo, en zou hij dus inmiddels al lang alles uit zijn cache moeten halen...

Als ik de afbeelding direct in de html duw doet ie het wel

Misschien een verkeerd idee, maar waarom maak je de url niet uniek?
Je getimage.php is momenteel niet echt te cachen omdat die telkens verandert ( vanuit de browser gezien ).
Iets als getimage.php?image=1 zou volgens mij beter te cachen zijn...

Afaik moeten exifs dit ook kunnen regelen, maar daar ben ik ook weer niet 100% zeker van. Maar met enkel cache headers ga je het imho niet redden zonder dat je een unieke url creeert.

[matthijsln]

De TS heeft trouwens in zijn bericht (onbedoeld?) een link naar zijn site staan in de Referer header.

Dat maakt een en ander duidelijk:
- Chrome 11 (linux) doet bij mij een vreemd request met headers als "If-Range: Fri, 15 Apr 2011 12:58:26 GMT
Range:bytes=125764-125764".
- Firefox reload de images niet, dus daar werkt de caching wel

...en de trage download zit mogelijk in de "mod_bwlimited/1.4"

En in Chrome werkt je crossfade script trouwens niet bij mij (plaatje verdwijnt direct). Gebruik liever dit script.

[ Voor 45% gewijzigd door matthijsln op 29-04-2011 16:45 ]

[CyBeR]

Browses hebben de neiging om requests met "dynamische content" niet te cachen en ook niet aan andere caching-achtige truukjes te doen. Een request met een querystring is een goed voorbeeld van een request met dynamische content.

Zet een rewriterule op met apache zodat je ipv getImage.php?id=123 kunt doen /image/123 of iets in die richting. Dan gaat je browser al wat meer meewerken. Zet er vervolgens een varnish tussen die dergeijke requests in geheugen cachet en dan ben je ook nog van een zooi http requests door je php heen af.

[BasieP]

Ik heb requests nu idd statisch gemaakt, door een /images/ directory te maken en dmv een .htaccess te rewriten.
dus '/images/12' wordt dan 'getImage.php?id=12'

Verder is precies waarom ik deze vraag stel omdat ik zag dat in Chrome het script niet werkt. Ik kan hier alleen geen touw aan vast knopen. Alle andere browsers doen het wel, en ding deed het in oudere versies van chrome ook.
Doordat ik toen ben gaan onderzoeken kwam ik op dit caching probleem.

het script waar je naar wijst gebruikt jquery. Iets waar ik eigenlijk niet zo graag aan wil. (omdat ik graag begrijp wat ik doe)
Ik doe in mijn script blijkbaar iets fout voor chrome. Ik los dat liever op dan dat ik alles overboord gooi.

(alhoewel het er wel lekker makkelijk uit ziet)

[ Voor 3% gewijzigd door BasieP op 03-05-2011 20:02 ]

[Spider.007]

kwaakvaak_v2 schreef op vrijdag 29 april 2011 @ 12:03:
Dan moet de maker van dat script eerst even wat oplossen

code:

/disk2/server/httpd/cgi-bin/spider.py:288: DeprecationWarning: raising a string exception is deprecated raise Error, http_status_codes.get(errcode, errmsg)

Voor volledige pagina's werkt het idd even niet, maar een directe link naar een afbeelding werkt perfect. Eventueel gebruik je de opvolger: http://redbot.org/