[PHP] tijdelijke afbeelding vewijderen

[Elvis]

Goeiemorgen GoT,

Ik heb voor mijn gallery een script geschreven dat afbeeldingen die groter zijn dan 640x480px verkleint (naar 640x480px).
Dit bestand opgeslagen in een tijdelijke map.
Om ervoor te zorgen dat de server niet vol komt te staan met al die kleinere bestandjes, wil ik ze ook terug verwijderen mbv

PHP:

unlink($temp_afb)

Als ik deze regel echter invoer aan het eind van mijn page, wordt de afbeelding al verwijderd voordat ze kan bekeken worden...
Wat natuurlijk niet de bedoeling is...
Heeft iemand enkele tips?

[Pyrus]

Functie schrijven die alle bestanden in de temp dir uitleest en als $datum-$datum_gemaakt>aantal dagen dat tmp afbeelding te zien mag zijn unlink(); Dit vervolgens in een constructie als:

PHP:

if(rand(0,1000)>999){jedeletefunctie();}

Om het gemiddeld 1x per 1000 pageviews te laten deleten. Aantal pageviews natuuriljk te varieren naargelang drukte van je site

[EnsconcE]

Je kan het bekeken plaatje i.c.m. bekijk datum in een dbase bijhouden. Dan kun je zeggen dat het bestand 1 uur bekeken mag worden, als iemand dan je website bezoekt dan verwijdert hij alle "openstaande" afbeeldingen.

[Verwijderd]

bestaan er geen standaard cache frameworks? Want dan kun je simpelweg genereren en cachen.

Simpel.

[HansMij]

Je kunt het plaatje natuurlijk ook gewoon streamen. Dan hoef je hem niet eens meer te verwijderen.

[Elvis]

Bedankt voor de reacties allemaal.
Ik had ondertussen zelf al een oplossing gevonden (waar de les Frans al niet goed voor is )

Nu verwijderd het script alle bestanden in de map "temp" aan het begin van de page.
Daarna word de foto in kwestie verkleint en in "temp" gezet.

Als er meerdere users tegelijkertijd in de gallery aan het kijken zijn, bestaat er natuurlijk een héél minieme kans dat ze net in dezelfe microseconde hun pagina vernieuwen en de foto niet zien...
Maar dat zal misschien 1 keer om de 2 jaar voorvallen...

[EnsconcE]

Elvis schreef op dinsdag 05 december 2006 @ 10:37:
Bedankt voor de reacties allemaal.
Ik had ondertussen zelf al een oplossing gevonden (waar de les Frans al niet goed voor is )

Nu verwijderd het script alle bestanden in de map "temp" aan het begin van de page.
Daarna word de foto in kwestie verkleint en in "temp" gezet.

Als er meerdere users tegelijkertijd in de gallery aan het kijken zijn, bestaat er natuurlijk een héél minieme kans dat ze net in dezelfe microseconde hun pagina vernieuwen en de foto niet zien...
Maar dat zal misschien 1 keer om de 2 jaar voorvallen...

Om die reden kan je beter de plaatjes streamen, dan maak je alleen gebruik van de rekenkracht van je server en je voorkomt dat een plaatje verdwenen is.

[Janoz]

Als software ontwikkelaar zul je je altijd aan murphys law moeten houden. Sowieso is die marge veel groter dan enkele microseconden. Tot slot kun je nog allemaal problemen krijgen wanneer het ene script een bestand weg wil gooien dat apache toevallig nog net naar een gebruiker aan het sturen was. Als je toch alles zo snel mogelijk weg wilt gooien, waarom sla je het dan uberhaupt nog op op schijf en laat je het niet, zoals HansMij zegt, gewoon streamen? Dat lijkt me namelijk een stuk efficienter.

[sQuarecoW]

Plaatjes streamen??

* sQuarecoW hoort weer iets heel nieuws

[Voutloos]

Elvis schreef op dinsdag 05 december 2006 @ 10:37:
Als er meerdere users tegelijkertijd in de gallery aan het kijken zijn, bestaat er natuurlijk een héél minieme kans dat ze net in dezelfe microseconde hun pagina vernieuwen en de foto niet zien...
Maar dat zal misschien 1 keer om de 2 jaar voorvallen...

Alsjeblieft zeg, wat een instelling. Nofi, maar je bent aan het rommelen. Als je dit soort trucs vaker toepast of als je site populairder wordt, ga je op een gegeven moment echt ontzetten hard balen van dit soort constructies.

Overigens is de kans is echt groter, want de periode dat het fout kan gaan is echt langer dan 1 μs. Eerst loopt het script nog verder, dan moet de output nog door de browser geinterpreteerd worden, waarna pas het downloaden van afbeeldingen plaatsvindt. Het kan zelfs al makkelijk fout gaan als iemand meerdere links van je site tegelijk in meerdere tabs/venster laadt.
Overigens, als een user meerdere keren hetzelfde plaatje bekijkt, schaal je nu elke keer opnieuw het plaatje (mogelijk gooide je het temp plaatje zelfs weg aan het begin van diezelfde request ), dus ook voor serverload is het netter om bestanden een korte periode te bewaren. Als je het plaatje echt nooit wil bewaren, bewaar het dan ook niet, maar stream het.

[Skaah]

Elvis schreef op dinsdag 05 december 2006 @ 06:36:
Goeiemorgen GoT,

Ik heb voor mijn gallery een script geschreven dat afbeeldingen die groter zijn dan 640x480px verkleint (naar 640x480px).
Dit bestand opgeslagen in een tijdelijke map.
Om ervoor te zorgen dat de server niet vol komt te staan met al die kleinere bestandjes, wil ik ze ook

Dit is natuurlijk niet voor niets! Op deze manier kan de volgende die het plaatje opvraagt dit supersnel geleverd krijgen.

Volgens mij valt het hele ruimteprobleem ook reuze mee: ik heb 2,52 GB voor 3.742 foto's, hier hoort een cachemap bij met 21.068 bestanden (181MB, dat is net 7% van het origineel).

[ Voor 14% gewijzigd door Skaah op 05-12-2006 10:55 ]

[EnsconcE]

sQuarecoW schreef op dinsdag 05 december 2006 @ 10:49:
Plaatjes streamen??

* sQuarecoW hoort weer iets heel nieuws

PHP:

header('Content-Type: image/jpeg');
header('Content-Length: ' . filesize($image));
header('Content-Disposition: attachment; filename="' . $image . '"');

readfile($image);

Daarnaast is dit een stuk eenvoudiger en efficiënter om toe te passen. Je zit hiermee andere users nooit in de weg, wat Janoz al zegt.

Volgens mij valt het hele ruimteprobleem ook reuze mee: ik heb 2,52 GB voor 3.742 foto's, hier hoort een cachemap bij met 21.068 bestanden (181MB, dat is net 7% van het origineel).

Hoezo valt het ruimte probleem mee, jouw server is niet Elvis zijn server.

[Elvis]

sQuarecoW schreef op dinsdag 05 december 2006 @ 10:49:
Plaatjes streamen??

* sQuarecoW hoort weer iets heel nieuws

* Elvis weet ook niet wat voor beestje dat dat is...

Bij nader inzien heb ik dan toch maar besloten de kleinere versies te laten staan...
Misschien is de kans dat het script zichzelf tegenspreekt (bij meerdere bezoekers tegelijk) toch groter dan ik in den beginne dacht...

[MBV]

waarom doe je niet gewoon wat pyrus zegt: alle plaatjes ouder dan een week verwijderen? Er zijn functies in php om de datum te bepalen, dus zo moeilijk moet dat niet zijn.

[Voutloos]

EnsconcE schreef op dinsdag 05 december 2006 @ 11:11:
Daarnaast is dit een stuk eenvoudiger en efficiënter om toe te passen. Je zit hiermee andere users nooit in de weg, wat Janoz al zegt.

Efficient qua storagegebruik ja. Echter gaat het hier wel om een gallery en dan mag je toch wel er van uitgaan dat een bepaald album of foto vaker bekeken wordt, dus is thumbnails cachen waarschijnlijk in totaal efficienter.

Elvis schreef op dinsdag 05 december 2006 @ 11:11:
Bij nader inzien heb ik dan toch maar besloten de kleinere versies te laten staan...

OK, je kan het verbruik gewoon even aankijken en ondertussen jezelf inlezen over hoe je netjes op basis van ouderdom van bestanden kan opruimen, wat overigens echt niet zo moeilijk is.

[Verwijderd]

waarom gebruik je uberhaubt niet alleen plaatjes met die maximale grootte?? Dan ben je toch gelijk van het probleem af? Eventueel upload script zo aanpassen dat ie met GD gelijk de plaatjes kleiner maakt, eventueel gelijk met thumbnail (100x100??) voor previews, scheelt gelijk weer bandbreedte en de afmeting van zo'n plaatje lijkt me te verwaarlozen. (weet niet wat voor hosting je hebt uiteraard )

Ben wel benieuwd naar dat image stream verhaal... bedoelen jullie daarmee dat je voordat je het plaatje verwijderd eerst de "rauwe" jpg + headers naar de browser stuurt?

[Evilbee]

Verwijderd schreef op dinsdag 05 december 2006 @ 12:01:
waarom gebruik je uberhaubt niet alleen plaatjes met die maximale grootte?? Dan ben je toch gelijk van het probleem af? Eventueel upload script zo aanpassen dat ie met GD gelijk de plaatjes kleiner maakt, eventueel gelijk met thumbnail (100x100??) voor previews, scheelt gelijk weer bandbreedte en de afmeting van zo'n plaatje lijkt me te verwaarlozen. (weet niet wat voor hosting je hebt uiteraard )

Ben wel benieuwd naar dat image stream verhaal... bedoelen jullie daarmee dat je voordat je het plaatje verwijderd eerst de "rauwe" jpg + headers naar de browser stuurt?

In plaats van:

PHP:

$im = imagecreate(100, 50);
imagepng($im, 'image.jpg');

doe je

PHP:

$im = imagecreate(100, 50);
header("Content-type: image/png");
imagepng($im);

Dan wordt het plaatje dus niet opgeslagen, maar meteen naar de browser gestuurd.

[Verwijderd]

Ok... nice... en hoe performed dat vergeleken met het opslaan van thumbs, dus vs. on-demand resize-en?

ps. Dit is geen poging tot topic hijacking... maar mijns inziens een nuttige uitbreiding van het sub-onderwerpje image streaming.

[MBV]

Even goed of beter, omdat het niet naar de harde schijf hoeft. De enige reden waarom thumbnails 'altijd' op de harde schijf worden opgeslagen, is omdat de GD-library te traag is. Om een 'mooie' jpeg te genereren heeft hij bij mij meerdere seconden nodig, wat dus bij een serieuze load niet gaat werken. Dat wordt dus allemaal opgeslagen, en nooit meer weggegooid, omdat dat wél serieus veel performance scheelt. Zodra het nodig is wordt het met die methode van evilbee weer getoond.

Ik heb trouwens goede ervaringen met imagemagick, veel sneller dan GD

[EnsconcE]

MBV schreef op dinsdag 05 december 2006 @ 15:56:
Even goed of beter, omdat het niet naar de harde schijf hoeft. De enige reden waarom thumbnails 'altijd' op de harde schijf worden opgeslagen, is omdat de GD-library te traag is. Om een 'mooie' jpeg te genereren heeft hij bij mij meerdere seconden nodig, wat dus bij een serieuze load niet gaat werken. Dat wordt dus allemaal opgeslagen, en nooit meer weggegooid, omdat dat wél serieus veel performance scheelt. Zodra het nodig is wordt het met die methode van evilbee weer getoond.

Ik heb trouwens goede ervaringen met imagemagick, veel sneller dan GD

Ik ben hier even aan het testen geweest, een image mooi resizen duurt gemiddeld 2 seconden per image. Ik heb een 1280*1024 plaat geresized naar 200*160:

PHP:

<?php
$mtime = microtime(); 
$mtime = explode(" ",$mtime); 
$mtime = $mtime[1] + $mtime[0]; 
$starttime = $mtime; 

// The file
$filename = 'test.jpg';

// Set a maximum height and width
$width = 200;
$height = 200;

// Content type
header('Content-type: image/jpeg');

// Get new dimensions
list($width_orig, $height_orig) = getimagesize($filename);

$ratio_orig = $width_orig/$height_orig;

if ($width/$height > $ratio_orig) {
    $width = $height * $ratio_orig;
}
else {
    $height = $width / $ratio_orig;
}

// Resample
$image_p = imagecreatetruecolor($width, $height);
$image = imagecreatefromjpeg($filename);
imagecopyresampled($image_p, $image, 0, 0, 0, 0, $width, $height, $width_orig, $height_orig);

//decide the amount of the apache has taken to interpet this image
$mtime = microtime();  
$mtime = explode(" ",$mtime);  
$mtime = $mtime[1] + $mtime[0];  
$endtime = $mtime;  
$totaltime = round(($endtime - $starttime), 2);

$black  = imagecolorallocate($image, 0, 0, 0);
$fontSize = 1;
imagestring($image_p, $fontSize, 0, 0, $totaltime, $black);

// Output
imagejpeg($image_p, null, 100);
imagedestroy($image_p);
?>

[Janoz]

Verwijderd schreef op dinsdag 05 december 2006 @ 15:42:
Ok... nice... en hoe performed dat vergeleken met het opslaan van thumbs, dus vs. on-demand resize-en?

ps. Dit is geen poging tot topic hijacking... maar mijns inziens een nuttige uitbreiding van het sub-onderwerpje image streaming.

Cachen is altijd handig als je genoeg ruimte hebt. De thumbnail operatie is redelijk duur.

Een thumbnail maken, deze wegschrijven naar de harde schijf en nadat deze is verstuurd zo snel mogelijk weer willen verwijderen is compleet onzinnig.

[MBV]

EnsconcE schreef op dinsdag 05 december 2006 @ 16:14:
[...]


Ik ben hier even aan het testen geweest, een image mooi resizen duurt gemiddeld 2 seconden per image. Ik heb een 1280*1024 plaat geresized naar 200*160:

code:

...

Ik had het over 6MPix foto's resizen naar 200*150 op een K6-2 450MHz. Dat duurt een paar seconden met GD, en ongeveer 1 sec met magick. Op mijn vorige laptop duurde het iets van 2 sec per foto met GD (op windows, P4 1.4GHz). uiteraard met resampling.

[Verwijderd]

Het is natuurlijk ook wel een kwestie van "waar gebruik ik dit voor", als ik een thumbnail overzicht wil geven van afbeeldingen in een galerij, heeft dit natuurlijk niet zoveel zin?

[EnsconcE]

Dat ligt aan je doel, snel een thumbnail laten zien of je programmeerkunsten op beeld presenteren

[MBV]

Verwijderd schreef op dinsdag 05 december 2006 @ 19:58:
Het is natuurlijk ook wel een kwestie van "waar gebruik ik dit voor", als ik een thumbnail overzicht wil geven van afbeeldingen in een galerij, heeft dit natuurlijk niet zoveel zin?

Júist voor een thumbnailoverzicht is 2sec per thumbnail écht niet te doen. Dan moet je dus voor 25 foto's bijna een minuut wachten! Oftewel: cachen is zeker noodzakelijk, ook als er maar 1 persoon tegelijk kijkt

[HansMij]

MBV schreef op dinsdag 05 december 2006 @ 21:42:
[...]


Júist voor een thumbnailoverzicht is 2sec per thumbnail écht niet te doen. Dan moet je dus voor 25 foto's bijna een minuut wachten! Oftewel: cachen is zeker noodzakelijk, ook als er maar 1 persoon tegelijk kijkt

Ik heb laatst voor een zwager zo'n index-pagina gemaakt, deze heb ik het even opezocht, hij laat 53 ge-resizete plaatjes binnen 7 seconden zien.

Ik ben het eens met het feit dat het eigenlijk not done is om op die manier een gallery te maken. (vergt erg veel van de processor, en op de server wordt hij waarschijnlijk door Apache toch wel weer gecached naar de hdd). Maar zo hoeft m'n zwager alleen maar foto's te uploaden om die pagina te vullen. (het script zoekt namelijk de directory-structuur af voor het menu, en als je op het menu-item klikt, speurt hij de betreffende directory af naar foto's om te resizen.) Je spaart er qua performance dus niets mee uit om te streamen, alleen hoef je zelf niet bij te houden welke foto's al dan niet verwijderd dienen te worden.

[Wim-Bart]

Streamen is helemaal niet zo een slechte optie, zeker niet voor een Image gallerij. Wanneer je browser goed werkt dan valt de overhead van GD en GD2 nog wel mee doordat er een aantal simultane streams naar de server gaan. Neem bijvoorbeeld de volgende HTML code

HTML:

<IMG SRC="/include/scaleimage.php?img=/images/biga.jpg" ALT="Thumb" TITLE="Thumb">
<IMG SRC="/include/scaleimage.php?img=/images/bigb.jpg" ALT="Thumb" TITLE="Thumb">
<IMG SRC="/include/scaleimage.php?img=/images/bigc.jpg" ALT="Thumb" TITLE="Thumb">
<IMG SRC="/include/scaleimage.php?img=/images/bigd.jpg" ALT="Thumb" TITLE="Thumb">

In princiepe lopen er op de server nu meerdere threads welke de images scalen waardoor de som van de tijd per image niet lineair kan worden berekend. Heeft een scale actie 2 seconden nodig dan zal het niet 2+2+2+2 seconden zijn maar veel sneller doordat er meerdere instances van PHP simultaan werken.

Een nadeel van deze methode is dat je wel X-maal de overhead hebt van PHP starten, initialiseren en andere overhead acties welke je niet hebt wanneer je de image genereerd en naar disk schrijft. Je moet dus zelf een aantal afwegingen maken en testen voordat je een bepaalde methode implementeert.

[Janoz]

De computer heeft een verwerkings kracht van x. Als jij 4 requests doet wordt die verwerkingskracht niet 4x. Meerdere request zorgen ervoor dat het scalen per plaatje langer zal gaan duren.

[Janoz]

HansMij schreef op woensdag 06 december 2006 @ 11:10:
[...]

Ik heb laatst voor een zwager zo'n index-pagina gemaakt, deze heb ik het even opezocht, hij laat 53 ge-resizete plaatjes binnen 7 seconden zien.

Ik ben het eens met het feit dat het eigenlijk not done is om op die manier een gallery te maken. (vergt erg veel van de processor, en op de server wordt hij waarschijnlijk door Apache toch wel weer gecached naar de hdd). Maar zo hoeft m'n zwager alleen maar foto's te uploaden om die pagina te vullen. (het script zoekt namelijk de directory-structuur af voor het menu, en als je op het menu-item klikt, speurt hij de betreffende directory af naar foto's om te resizen.) Je spaart er qua performance dus niets mee uit om te streamen, alleen hoef je zelf niet bij te houden welke foto's al dan niet verwijderd dienen te worden.

Een simpele controle die kijkt of de gegenereerde benodigde versie nieuwer is dan degene die je bij je dirscan gevonden hebt is een stuk minder zwaar dan de hele conversie uitvoeren.

[MBV]

HansMij schreef op woensdag 06 december 2006 @ 11:10:
[...]

Ik heb laatst voor een zwager zo'n index-pagina gemaakt, deze heb ik het even opezocht, hij laat 53 ge-resizete plaatjes binnen 7 seconden zien.

Ik ben het eens met het feit dat het eigenlijk not done is om op die manier een gallery te maken. (vergt erg veel van de processor, en op de server wordt hij waarschijnlijk door Apache toch wel weer gecached naar de hdd). Maar zo hoeft m'n zwager alleen maar foto's te uploaden om die pagina te vullen. (het script zoekt namelijk de directory-structuur af voor het menu, en als je op het menu-item klikt, speurt hij de betreffende directory af naar foto's om te resizen.) Je spaart er qua performance dus niets mee uit om te streamen, alleen hoef je zelf niet bij te houden welke foto's al dan niet verwijderd dienen te worden.

Mijn uitgangspunt was voor mijn eigen website precies hetzelfde: ik wil plaatjes in een map dumpen, en mijn website moet zelf alle caches en indexes genereren. Ik stream daarbij de images: als er geen cache is genereer ik dat, en stream het plaatje, als het cache er wel is stream ik het bestand. Op die manier hoef ik alleen maar de bestanden te dumpen in de map, en de rest gebeurt vanzelf.
Het enige wat eens in de zoveel tijd moet gebeuren is een script draaien dat overtollige cache weggooit, ook draai ik wel eens een script dat alle thumbnails opvraagt (lekker lui: alle thumbnails in HTML zetten en de browser laten opvragen )
http://mvdvlist.nl/images_new/ is mijn site, als je code wilt zien roep maar. Het is de bedoeling om het ooit onder GPL vrij te geven, maar eigenlijk is dat redelijk doelloos gezien de berg GPL scripts die hetzelfde doet. 't Was een leerprojectje voor mij om OOD/OOP in PHP toe te passen, dus heel erg nette code (hoop ik )

[MTWZZ]

^^ Dat is ook ongeveer wat ik doe op mijn server maar dan nog uitgebreid met Not-Modified / Expires headers, Hotlink preventie en custom ETags.
Dat scheelt sowiezo aan de client kant al omdat de browser al kan bepalen of er opnieuw iets opgehaald moet worden.

[ Voor 7% gewijzigd door MTWZZ op 06-12-2006 14:01 ]

[Skaah]

MTWZZ schreef op woensdag 06 december 2006 @ 13:56:
^^ Dat is ook ongeveer wat ik doe op mijn server maar dan nog uitgebreid met Not-Modified / Expires headers, Hotlink preventie en custom ETags.
Dat scheelt sowiezo aan de client kant al omdat de browser al kan bepalen of er opnieuw iets opgehaald moet worden.

Klopt, vooral Last-Modified in combinatie met 304 Not Modified scheelt heel erg in de snelheidsbeleving. Maak daar dus gebruik van.