[PHP/SQL] Aanpak gallery caching

[Kiphaas7]

Excuses voor de ietwat vage omschrijving, ik ben niet zo vaak actief met programming. Hierna zal ik het probleem misschien wat omslachtig omschrijven

korte omschrijving: Ik ben bezig een drupal module te schrijven die een simpele gallery moet gaan voorstellen. Bestaande modules voldoen niet aan mijn eisen, en een standalone pakket is geen optie. Deze gallery moet, op basis van een vooraf gedefineerd pad, een album structuur opbouwen die ook in dat pad aanwezig is:

code:

-fotos
--map1
---foto1
---foto2
--map2
---foto3

Voor die gallery heb ik een aantal voorwaardes, waarvan er twee van belang zijn voor dit topic, namelijk lazy-loading (thumbnails maken en cachen als deze niet bestaan, en record aanmaken in db), en *tromgeroffel* snelheid. De db record heb ik (volgens mij) absoluut nodig om allerlei sorting options, ratings etc mogelijk te maken.

Nou snap ik wel dat deze twee elkaar een beetje in de weg staan (alleen uit de db lezen is natuurlijk een stuk sneller), maar vroeg ik me af of ik de meest efficiente structuur te pakken heb, en zo nee, wat anders kan om te optimaliseren. Een voorbeeld:

1. User bezoekt url die correspondeert met een bepaald submap in de fotomap
2. code bouwt array op met alle bestanden aanwezig in die submap
3. code haalt alle map gerelateerde records uit de db
4. code vergelijkt db waardes met array van mapbestanden, en filtert op nieuwe/verwijderde bestanden
5. code update de db met de nieuwe records, en delete de verwijderde fotorecords
6. code cached nieuwe thumbnails en delete verwijderde thumbnails
7. code bouwt het album op en toont het aan de user

Op een of andere manier voelt het omslachtig aan. Bedenk dat ik een prutsert ben die het coden heeft "geleerd" van internettutorials doornemen, en niet al te beste daarvan. Tips over hoe ik de structuur kan optimaliseren zijn van harte welkom, de code die erbij hoort kan ik best zelf achterkomen.

edit:

Waar ik zelf nog aan gedacht heb:
Array van bestanden vergelijken met array van cache ipv db, thumbnail maken en cachen, daarna pas db updaten. Dit klinkt voor mij als een iets andere, maar net zo snelle weg naar hetzelfde doel....

[ Voor 5% gewijzigd door Kiphaas7 op 10-06-2009 01:28 ]

[disjfa]

Cache de thumbnail als het plaatje eerder gemaakt is dan de aangemaakte datum van het plaatje (filemtime) en output het plaatje als de http headers het niet niet hebben laten zien.

De rest is alleen database dus moet je wel ophalen. Maar schrijf geen plaatjes weg in een database. (alleen de url dus)

[ Voor 3% gewijzigd door disjfa op 10-06-2009 01:29 ]

[Kiphaas7]

disjfa schreef op woensdag 10 juni 2009 @ 01:29:
De rest is alleen database dus moet je wel ophalen. Maar schrijf geen plaatjes weg in een database. (alleen de url dus)

Dat was ook de bedoeling, sorry voor de onduidelijkheid....

disjfa schreef op woensdag 10 juni 2009 @ 01:29:
Cache de thumbnail als het plaatje eerder gemaakt is dan de aangemaakte datum van het plaatje (filemtime)

Hier raak ik je volledig kwijt.... Ik snap niet wat welke datum je wilt vergelijken met de filemtime datum. Als je het over EXIF data hebt (lijkt me sterk), dat is toch alleen voor jpg bestanden?

disjfa schreef op woensdag 10 juni 2009 @ 01:29:
en output het plaatje als de http headers het niet niet hebben laten zien.

Eh? http headers worden toch verstuurd van de user? Met cachen bedoel ik een thumbnail aanmaken in een dir op de server, niet bij de client... Of ben ik je hier ook volledig kwijt?

[Kiphaas7]

*Subtiele schop*

[mithras]

Allereerst: kijk anders eens naar Zen Photo. Zij hebben in de database de permissies staan, maar de folderstructuur van het FS wordt aangehouden.

Om op je vragen in te gaan: afbeeldingen worden fullsize geupload. Door het uploaden krijgen ze een create timestamp mee op het fs. Deze kan je ophalen met php en bekijken. Je hebt een folder waarin je cache images staan. Bestaat de image nog niet, of heeft de cache image een timestamp die eerder ligt dan de fullsize foto, dan moet je dus de cache opnieuw aanmaken.

Je kan je db slechts gebruiken om te kijken of bezoekers toegang hebben tot het album. Denk er wel aan: als je eenmaal de locatie van de foto kent, zal je met deze methode altijd de foto kunnen opvragen. Of je nu wel of niet de rechten hebt!

[Johnny]

Ik ben een tijdje terug begonnen met iets soortgelijks, een collectie PHP classes waarmee afbeeldingen in verschillende resoluties kunnen worden aangeboden wat kan worden geintegreerd op iedere website waarbij gebruikers afbeeldingen kunnen uploaden. Het is nog niet echt uit ontwikkeld, maar zijn wat conceptten waarop het gebaseerd is waar je misschien wat aan hebt:

- Een directory waarvan de naam eindigt op .gallery wordt een galerij genoemd en bevat afbeeldingen, anders bevat hij enkel andere directories of galerijen.
- Iedere afbeelding heeft een eigen directory binnen de galerij met daarin het originele bestand.
- Iedere afbeelding heeft een eigen cache, deze staat standaard bij de afbeelding maar kan ook in een andere locatie staan (bijbvoorbeeld in /tmp) waar eenzelfde structuur staat, alleen dan zonder de originelen.
- De naam van het gecachte bestand is ook meteen een beschrijving er van (resolutie, kwaliteit, cropmethode), hiermee kan je makkelijk zien of er al een gecachte versie is.
- In het configuratiebestand kan je doormiddel van named presets een beschrijving van een gecachte versie maken.

Een preset:

code:

[preset:medium]
width = 128
height = 128
extension = jpg
quality = 80
sharpening = 1
metadata = 0
resize = crop

code:

-library
--directory
---directory.gallery
----image1
-----image1.jpg (origineel)
-----cache
------image1.128x128_c.jpg
------image1.300x200_p.jpg

Als je dan vervolgens de volgende URL oproept:
http://example.com/image/direcory/image1:medium.jpg

Dan wordt de gevraagde bestandsnaam eerst opgebroken "directory" is de laatste (in dit geval ook de eerste) directory voor de bestandsnaam dus de gallery. Het pas van de library wordt altijd aan de voorkant toegevoegd, het pad wordt dan:

/path/to/library/directory.gallery/

De naam van de afbeelding wordt gesplitst op de : gevolgd door de naam van de preset (origineel wanneer er geen preset is). In de configuratie wordt gekeken welke eigenschappen die preset heeft en kan dus de bestandsnaam van de gecachte versie worden opgebouwd:

/path/to/library/directory.gallery/image1/cache/image1.128x128_c.jpg

En dat bestand wordt teruggestuurd naar de gebruiker. Er wordt niet steeds gecontroleerd of afbeeldingen in het cache nog wel nodig zijn, dat is veel efficienter om dat periodiek te doen via een cron job. Ook is er geen database nodig (is wel de bedoeling dat het later kan) en is alle metadata (EXIF, IPTC, XMP) van afbeeldingen uit te lezen en kunnen ze er ook op worden gesorteerd.

[Kiphaas7]

mithras schreef op donderdag 11 juni 2009 @ 11:44:
Allereerst: kijk anders eens naar Zen Photo. Zij hebben in de database de permissies staan, maar de folderstructuur van het FS wordt aangehouden.

Ik had al losjes naar zenphoto gekeken, daar komt eigenlijk ook het hele idee van mij vandaan:
http://www.zenphoto.org/w...-12-image-discovery12.jpg

Om op je vragen in te gaan: afbeeldingen worden fullsize geupload. Door het uploaden krijgen ze een create timestamp mee op het fs. Deze kan je ophalen met php en bekijken. Je hebt een folder waarin je cache images staan. Bestaat de image nog niet, of heeft de cache image een timestamp die eerder ligt dan de fullsize foto, dan moet je dus de cache opnieuw aanmaken.

Duidelijk, daar moet ik inderdaad op letten.

Je kan je db slechts gebruiken om te kijken of bezoekers toegang hebben tot het album. Denk er wel aan: als je eenmaal de locatie van de foto kent, zal je met deze methode altijd de foto kunnen opvragen. Of je nu wel of niet de rechten hebt!

Daar heb ik geen problemen mee. In principe heb ik niet zo'n fijnmazige rechtenstructuur nodig, ik ontwikkel deze drupal module voor een kleine website, waar sowieso iedereen, inclusief gasten, de fotos mogen zien. De database wil ik enkel en alleen gebruiken om bijvoorbeeld ieder plaatje een rating te geven, en om allerlei sorting options (sorten op rating..) mogelijk te maken.

Johnny schreef op donderdag 11 juni 2009 @ 12:16:
heel verhaal

Ik waardeer het ontzettend dat je de moeite neemt om het me helemaal uit te leggen, maar ik heb het niet nodig. Het voordeel van werken met drupal is dat er allerlei handige modules zijn, zoals imagecache. Daar zit een hele API bij, dus over het cachen an sich hoef ik me geen zorgen te maken, dat wordt goed geregeld.

Johnny schreef op donderdag 11 juni 2009 @ 12:16:
Er wordt niet steeds gecontroleerd of afbeeldingen in het cache nog wel nodig zijn, dat is veel efficienter om dat periodiek te doen via een cron job. Ook is er geen database nodig (is wel de bedoeling dat het later kan) en is alle metadata (EXIF, IPTC, XMP) van afbeeldingen uit te lezen en kunnen ze er ook op worden gesorteerd.

Database heb ik nodig voor bovenstaande redenen.

Cronjob vind ik zelf niet handig, omdat ik perse "upload and forget" wil hebben. Dat deze keuze minder efficient is, wist ik van tevoren. Echter maak ik het voor een kleine website, waar gemak boven snelheid gaat.

Dat gezegd hebbende, wil ik voor mijn designkeuze (lazy-load) wel de meest efficiente code hebben, en dat is de waarom ik dit topic geopend heb. Om de overhead die ik introduceer met mijn ontwerpkeuze tot een minimum te beperken.