[PHP] cachen van resized images in file of db?

[Verwijderd]

Na ervaren te hebben dat het resizen met GDlib niet altijd even snel gaat en redelijk aan je systeem vreet, heb ik toch wel geconcludeerd dat het voor een een kleine site al lonend kan zijn om deze images eenmalig (bij het eerste opvragen) te resizen, en te cachen, en later door het zelfde script uit een file of database te laten parsen.

MAAR: wat is wijsheid in dit geval? files of een database? database lijkt me wat flexibeler (ik draai trouwens MySQL) en makkelijker beheerbaar (delete alles wat ouder is als ... enzo) maar ik heb het idee dat files sneller zijn klopt dit? en maakt het voor mijn (hooguit 400 bezoekers per dag) zo veel uit? weegt het op tegen de nadelen in files? of is het zowiezo not-done om dikke files als plaatjes in een mysql database te gooien?

any sugestions on this? heb niks kunnen vinden met de (omega) search o.a.

[Verwijderd]

welke nadelen? files voor plaatjes willen juist heel goed.
dan kan je gewoon de is dan kun je it het script gewoon een
header("Location:plaatje.gif");
doen.
dit gaat natuurlijk sneller dan via de database in je script laden en via je script op het scherm zetten

[drm]

Ik vind 't eerlijk gezegd helemaal niet rielekst om met plaatjes in een db te werken. Het heeft eigenlijk geen voordelen ten opzicht van plaatjes opslaan als files, en files zijn sneller.

imho belast je de db-server onnodig veel door de plaatjes in de database op te slaan....

[Verwijderd]

drm schreef op 22 December 2002 @ 10:40:
Ik vind 't eerlijk gezegd helemaal niet rielekst om met plaatjes in een db te werken. Het heeft eigenlijk geen voordelen ten opzicht van plaatjes opslaan als files, en files zijn sneller.

imho belast je de db-server onnodig veel door de plaatjes in de database op te slaan....

Wanneer je niet beschikt over een server waarbij je mappen niet kan beveiligen is het wel de oplossing. Wanneer je ze in een apparte tabel opslaat en gewoon in goed jpg formaat zet valt het allemaal reuze mee.

[ACM]

Een map hoeft ook niet beveiligd te zijn, gewoon niet in je documentroot

En ze in jpg in een aparte tabel is nog steeds een behoorlijke belasting van je databaseserver.

[Helmet]

ik zou ze ook gewoon als file opslaan hoor.
Met een database zou je wel eenvoudiger zoekfuncties ofzo kunnen inbouwen

[ACM]

Helmet schreef op 22 December 2002 @ 15:11:
ik zou ze ook gewoon als file opslaan hoor.
Met een database zou je wel eenvoudiger zoekfuncties ofzo kunnen inbouwen

Je kan altijd de metadata van de files nog in de DB opslaan (locatie, extra info etc) en daardoor net zo goed kunnen zoeken

[Helmet]

ACM schreef op 22 december 2002 @ 15:18:

[...]

Je kan altijd de metadata van de files nog in de DB opslaan (locatie, extra info etc) en daardoor net zo goed kunnen zoeken

mjah daar had ik inderdaad ook al aan gedacht gewoon info in de db gooien

[drm]

En dan nog, hoe wou je in binaire data gaan zoeken?

edit:

beter gezegd wat wou je in binaire data gaan zoeken?

[ Voor 39% gewijzigd door drm op 23-12-2002 09:41 ]

[Verwijderd]

het worden dus files, dat is duidelijk misschien met een dbtje voor de info, dat moet ik nog maar eens uitzoeken of dat nut heeft voor mij.

Ik wil dus een resize.php?f=file.jpg&w=400&h=300 ideetje zeg maar (ik neem aan dat dat de meeste genoeg zegt, icm mijn startpost). En als een image van die maat niet aanwezig is in de cachedir, dat ie em dan resized en wegschrijft, anders d.m.v. Header("Location: pic.jpg"); doorstuurt. Op deze manier zijn files dus anyhow handiger ( </conclusie> )

[ACM]

wat je kan doen is alle files op een standaard manier "encoden":
400_300_file.jpg (dus "{$w}_{$h}_{$f}") waarbij je er voor de veiligheid nog even op moet letten dat $f geen spaties, $, \ en / bevat en $w/$h getallen zijn

En dan is een file_exists voldoende om te achterhalen of ie al in de cache zit
Wat je trouwens ipv die location-header ook kan doen is een readfile(); maar dat is wel iets slomer/wordt niet zomaar gecached door de browser.

[ Voor 3% gewijzigd door ACM op 23-12-2002 12:42 ]

[Verwijderd]

ACM schreef op 23 December 2002 @ 12:42:
wat je kan doen is alle files op een standaard manier "encoden":
400_300_file.jpg (dus "{$w}_{$h}_{$f}") waarbij je er voor de veiligheid nog even op moet letten dat $f geen spaties, $, \ en / bevat en $w/$h getallen zijn

dat was ongeveer exact wat ik van plan was, lijkt me inderdaad wel het makkelijkste

Zou ik nog iets in moeten bouwen om evt het aantal resizes per host per uur te limiten ofzo? ik kan me voorstellen dat dit mogelijk misbruikt kan worden, gewoon al mijn capaciteit opvreten door mass-resize ofzo.

of ben ik nou paranoide

[drm]

Als er een "mass-resize" op zou treden zoals jij al zegt, dan is er volgens mij iets mis met je caching systeem

[ACM]

Verwijderd schreef op 23 December 2002 @ 13:02:
dat was ongeveer exact wat ik van plan was, lijkt me inderdaad wel het makkelijkste

Zou ik nog iets in moeten bouwen om evt het aantal resizes per host per uur te limiten ofzo? ik kan me voorstellen dat dit mogelijk misbruikt kan worden, gewoon al mijn capaciteit opvreten door mass-resize ofzo.

of ben ik nou paranoide

De $w en $h alleen een paar vaste waardes aan laten nemen?
Verder is er weinig tegen DoS attacks te doen en zullen allerlei checks om te kijken of iets X keer voorkwam in Y tijd eerder verslechterend dan verbeterend optreden

[djluc]

Ik zou er toch maar een beveiliging voor inbouwen, een dos mag dan wel niet echt te voorkomen zijn, je kunt er tochwel wat beveiligingen voor inbouwen.

[Verwijderd]

m'n scriptje werkt. erg mooi ook, al zeg ik het zelf.

maar dan heb ik nog een puntje: die gecachede items, hoeven niet voor eeuwig te blijven staan, das zelfs onwenselijk, hierdoor kan de quota vol raken. Ook is een cronjob niet echt een oplossing (niet bij alle sites waar ik dit toe wil gaan passen heb ik daar toegang toe), en ik denk dat zodra de cache een beetje groeit, (paar honderd items) het behoorlijk ten koste van de snelheid gaat om steeds bij elke request te checken op te oude items

een 'prune cache'-button in het site-beheersysteem zou een oplossing kunnen zijn, maar liever heb ik het natuurlijk automatisch (en dus zonder cron of iets dergelijks). ideeen? ik loop een beetje vast hier.

[Verwijderd]

Sla iedere keer dat een item gecached wordt de datum op. Vergelijk de huidige datum met die waarop het script voor het laatst gedraaid werd, en als het een nieuwe dag is, delete dan de gewenste items (bijv. die van X dagen geleden, of dde oudste Y files). Zo wordt de cache 1 keer per dag opgeschoond, uitgaande dat het script minimaal 1 keer per dag wordt gedraaid.

HTH