Een bestand, 1000 iconen

Waarom zal je in hemels naam PHP belasten met de opslag van afbeeldingen. Elke keer als ik één afbeelding nodig hebt wordt dus een hele icon set in het geheugen geladen, zinloos want dit kan ook direct door de webserver afgehandeld worden. Bespaart geheugen en snelheid.

Daarnaast vergeet je mime-types mee te sturen bij het 'uitspuggen' van het plaatje.

Waarom zou je zoiets willen? Echt nutteloos.

Oei, dit is juist niet wat je wilt! Het laden van een afbeelding via het bestandssyteem is vele malen sneller dan dat voor elke afbeelding je volledige PHP script geparsed moet worden.

Plaatjes zijn plaatjes, ga er dan ook geen fancy dingen omheen verzinnen. Overigens zie ik het voordeel van de nieuwe aanroep niet, de normale aanpak lijkt me veel eenvoudiger:

ps. Je zou natuurlijk ook nog kunnen overwegen om alle afbeeldingen in één zip bestandje te zetten en deze met PHP uit te lezen. Eh, of toch maar niet?!?

Grappig bedacht maar ik denk dat het toch niet heel erg handig is.
Mocht je erg veel gebruik maken van icoontjes kan je beter alle icoontjes op 1 afbeelding zetten en dmv CSS een stuk van het plaatje laten weergeven. ( 1 icoontje dus )

Dit is ook zoiets! Nu moet je dus voor het tonen van 1 simpel icoontje van 1 of 2 kb de hele afbeelding met alle icoontjes inladen? Alle 1000 icoontjes op 1 afbeelding, levert als snel een afbeelding die vele malen groter is dan die 2 kb van dat ene icoontje!

Wat is er toch mis met gewoon alle icoontjes in een map 'icons' dumpen (eventueel gebruik makend van submappen voor het overzicht) en gewoon de normale gangbare methode gebruiken?

Ik zie hier geen nut van in persoonlijk...

Het enige wat je door php wilt halen qua afbeeldingen zijn dynamische afbeeldingen (gd/imagemagick) zodat je no-cache headers mee kan geven.
Dit kan je dan nog beter via apache doen als je dat draait natuurlijk...

Of als er bepaalde rechten aan zitten van bepaalde gebruikersgroepen o.i.d.

De rest verandert toch niet/nauwelijks lijkt me... Dus zonde van de overhead hoe minimaal ook..

Ik heb zelf een dynamisch update systeem waarmee het gehele systeem (website of data beheer applicatie) geupdate kan worden, dit bestaat uit ongeveer 900 bestanden per php versie, met die iconen zou dit aantal verdubbelen waardoor de update-tijd gewoon vele malen langer werd. Dit was dan ook mijn motivatie om er een enkel bestand van te maken.

Als dat je eisen zijn lijkt mij het handiger om de iconen in 1 archiefbestand (binair, alles achter elkaar geplakt met in het begin een index vanaf welke offset welk icoontje begint) te nemen zodat PHP niet alle icoontjes hoeft in te lezen en te parsen. Beetje zoals een jar-bestand. Of je gebruikt er gewoon zip voor.

@Jelmer: Klinkt wel interessant, ik heb geen idee hoe ik dit aan zou moeten pakken, maar het lijkt me dat php daar drukker mee is dan met een bestandje van 1MB in het geheugen laden, welke bij frequent gebruik ook nog wordt gecached.

je kan met CSS naar een bepaald punt van een image gaan zeg maar...
over x,y as. Kijk eens naar dat sterren script wat in de library staat...
Dan kan je ze gewoon aan elkaar plakken allemaal...

En dat zou je weer kunnen automatiseren met GD/imagemagick eventueel..

Maar nogmaals de vraag... hoe vaak komen er nieuwe bestanden bij? En of gaan er oude weg? of wijzigt er wat? Als het een paar bestanden zijn zie ik nog geen reden ze door php te halen..

statische afbeeldingen worden gewoon door IIS / apache afgehandelt. Nu moet php de bestanden afhandelen en IIS / Apache weer php...

Kan wel nuttig zijn in sommige gevallen maar in deze snap ik het niet.
Maar wellicht vind iemand anders het ook wel handig...

Maar dan heb ik het ook over het gebruik van veel icoontjes, niet over 1 of 2. Maar als je erg veel gebruikt maakt van icoontjes dan kan je ze beter allemaal in 1 x laden.

GD is relatief nogal geheugen intensief...
hoogte * breedte * bytes
kan je dus wel van te voren uit rekenen ;)

bij een 32 bit alpha png kan dat aardig oplopen!

imagefilledarc en imagefilledpolygon vallen dan nog mee net als het resultaat overigens. Maar dat is een ander verhaal...

Als je ook nog aan de slag gaat wel setpixel(); e.d. en dus pixel voor pixel een afbeelding door loopt wordt het nog iets zwaarder meestal..
Waar je overigens wel de gaafste dingen mee kan doen!

On-the-fly GD gebruik behalve kleine captha's e.d. zou ik je iig niet aanbevelen...

@Lode: Gelukkig dan maar dat dit script geen GD2 gebruikt het is gewoon een platte opslag van png bestanden, er wordt ook geen compressie of iets dergelijks toe gepast, slechts een enkele base64_decode om de png data terug te converteren naar binair (slaat lastig op icm php normaliter).

"Een bestand, duizend iconen"...klinkt als de titel van een goed boek! ;)

Ander vraagje, gebruik je al die 1000 icoontjes ook echt? Zo ja, is dat niet een beetje overkill?

Je ziet iets over het hoofd. Natuurlijk klinkt het als onzin, maar er is wel degelijk een moment dat dit efficienter is.

Een kleine situatie:
1000 icoontjes van 1 kb in 1 bestand maakt een bestand van 1000kb.

Wanneer je 1 icoon nodig hebt, heb je 1 http request en laad je 1000kb terwijl je er maar 1 kb gebruikt.
conclusie: inefficient.

Wanneer je 10 icoontjes nodig hebt, heb je 1 http request(anders 10) en laad je 1000kb terwijl je er maar 10 kb gebruikt.
conclusie: inefficient.

Wanneer je 30 icoontjes nodig hebt, heb je 1 http request(anders 30) en laad je 1000kb terwijl je er maar 30 kb gebruikt.
conclusie: absoluut Efficient!.

De bottleneck is namelijk al die http requests! Als je die kan weg doen door al je icoontjes te laden in 1 request is er al snel een punt van laadtijd winst en dus snelheidswinst. Je wilt niet 30 keer een verbinding met de server opnieuw aangaan. De overbodige kb's vallen dan al snel in het niets.

Wanneer gebruik je 30 van die icoontjes tegelijkertijd op 1 pagina, en is het dan alsnog goed te praten dat je 1000 icoontjes laadt terwijl je er maar 30 nodig hebt? Kan je dan niet gewoon beter een keuze maken, en 1 plaatje met 30 maken in plaats van 1 veel te groot plaatje met 1000 waarvan je er 800 zeker niet zal gebruiken?

ik gebruik voor een UBB script de iconen van famfam heb het nu op beide manieren geprobeerd en vind het prachtig en werkt veel sneller zeker bij het heraanmaken van de iconen die ik gebruik in een UBB script om bvb een andere kleur te geven.

voorbeeld van een script waar ik meer dan 30 iconen gebruik is:

http://www.jb-web.net/scripts/php/UBB2

klik op de groene vinkjes om de iconen te tonen.

http://www.jb-web.net/scripts/php/GD

daar is het script om ze opnieuw in te kleuren enz...

mits gebruik van dit script heb ik zeker veel tijdswinst op het 2 de script.

Mooi en zal zeker nuttig zijn voor sommige doeleinden in elk geval vind ik de gedachte erachter zeker niet mis....

@Jelmer... je mist me punt...wat je uiteindelij kzegt is het principe wat ik duidelijk wilde maken... alle 1000 iconen is idd wat overdreven... maar het principe dat minder http requests wel degelijk is af te wegen soms tegen het aantal kb

Paar verbeterpunten:
1. PHP als opslagmedium is geen goed uitgangspunt. Je code en inhoud zou gescheiden moeten zijn. Je zou afbeeldingen moeten kunnen veranderen zonder Afbeeldingen in PHP is wel een van de slechtste ideeen in de geschiedenis. Ik kan de werking van je script moeilijk beoordelen omdat het nauwelijks leesbaar is.

2. Het kan een goed idee zijn om icoontjes samen te stellen tot 1 bestand. Maar het is verstandiger om met php en GD één samengesteld bestand te creeeren en die te cachen, dan alle bestanden in een php bestand op te slaan. In dit geval sla je de plank COMPLEET mis, want je hebt nog steeds 1 http request per image. De load op de server is echter veel hoger, omdat bij het opvragen van één image, alle images in het geheugen worden geladen, en dan een image wordt teruggegeven.

3. Je script geeft geen valide mime headers.

Kortom, denk er nog een keer over na. Je verhaal gaat niet op, en dit is geen efficiente manier om je probleem op te lossen.

@Ypma:


Nee, voor elke image wordt een aparte http request gedaan in dit geval. Dus voor 10 icoontjes (10kb) wordt 10 x 1000kb (10MB!!) aan files gelezen, en wordt het php script 10 keer uitgevoerd. Vandaar dat de demo ook niet zo erg lekker loopt.

Ik heb het idee dat er verschillende verhalen door elkaar aan het lopen zijn. Het aantal request beperken lag namelijk niet in mijn doelstellingen bij het opzetten van dit script, dus zoals arend al aangeeft, zal het aantal request hierbij niet afnemen.

Ypma geeft aan het aantal request te kunnen beperken, dit gaat over de css methode met één grote afbeelding, in zijn voorbeeld wordt het bestand daadwerkelijk maar één maal gedownload, IE of FF haalt het spul wel uit het cache.

Over de header zijn ook al een paar opmerkingen geweest, ik wist zelf niet precies hoe dit zat, omdat de code van elke afbeelding exact hetzelfde is gebleven, alleen niet binair. Ik ben er vanuit gegaan dat de headers gewoon in dit bestand zitten, maar uit jullie verhalen maak ik op dat de headers door php verstuurd worden. Bij een verhelderend antwoord zal ik deze headers toevoegen.

Nog eenmaal recapitulerend: Ik heb dit gemaakt om het aantal bestanden te beperken met minimale toename van serverload.

Wat me ineens te binnen schiet, met dit script is het natuurlijk redelijk eenvoudig om meerdere icons in een bestand te parsen en vervolgens met css eruit te vissen.

Denk aan zoiets:
icons.php?filename[]=accept.png&filename[]=zoom.png&.......

Met GD kan deze afbeelding vervolgens snel worden samengesteld, alle afbeeldingen zijn al ingelezen en voorhanden.


Overigens het veelgehoorde verhaal over geheugen, het script zal hooguit één MB aan geheugen gebruiken en de parseoverhead is minimaal (wél aanwezig). Voor mij is het dit, of een klant die een aantal maal per dag een update binnen haalt en 20s of 40s moet wachten. Voor mij dus in het voordeel van dit script.

"Overigens het veelgehoorde verhaal over geheugen"

Het gaat om stabiliteit, durabiliteit en dus eiteindelijk qualiteit...

Als je een site met 100 bezoekers hebt per dag hoef je je misschien geen zorgen te maken. Wellicht als je op shared hosting zit?!

Maar on-the-fly GD en overmatig image gebruik belasten servers onnodig en zorgen dus voor inconsistentie in het geheugen gebruik...
Wat weer kan lijden tot allerlei andere ellende...

Kijk naar tweakers.net daarvan lag ook een keer een server plat waardoor de php zichtbaar was. Gelukkig beschermd met Zend Guard... Maar dan nog...

Het gaat om onnodig geheugen gebruik c.q. overkill hier denk ik...
Iets wat je beter kan voorkomen als genezen..

Hoe vaak hebben mensen het niet over cron's per minuut, GD on-the-Fly e.d. Met als doel...????

@Lode: Dit script gebruikt géén GD!

Ik ken php/GD/SQL vrij goed dus daar was ik wel achter...

Maar zoals ik eerder al zei...
Leuk dat je het deelt, wellicht hebben anderen er iets aan.
Maar persoonlijk geniet het niet mijn voorkeur.

En het liep een beetje offtopic inderdaad over GD...

@storeman: maar wel overbodig veel geheugen.

wtf, dit slaat echt nergens op. ten eerste het is jatten van fam's dataverkeer en ten tweede, waarom zou je dit willen. een beetje website kan die wel opslaan en zo onoverzichtelijk vind ik dat nou ook weer niet.

@Tommy: Prima, gebruik het of niet. Daarnaast heb ik met de eigenaar van famfamfam.com overlegd en valt dit prima binnen de licentie.

Mee eens, gebruik het of niet.
Als jij er niets aan hebt, gebruik je het toch niet? Dan moet je hier ook niet overal commentaar op leveren dat het nergens op slaat. Misschien voor jou niet nee, maar voor andere misschien wel!

Beetje meer respect voor dit script...

Voor dit soort problemen heb je "CSS Sprites". CSS Sprites zijn combi-afbeeldingen met bijvoorbeeld 20x20 icoontjes. Via CSS positioneer je deze afbeelding, zodat je alleen het icoon dat je nodig hebt laadt.

Voordeel is dat je voor ál je icoontjes maar 1 HTTP Request kwijt bent. Scheelt dus enorm in de performance!

Het genererren van die CSS Sprites zou je wél met PHP kunnen doen, dan moet je echter wel goed cachen zodat er niet voor iedere user een nieuwe sprite gegenereerd word.

Het script doet mij een beetje denken aan mijn installer voor PHP scripts ;)

http://www.google.nl/search?hl=nl&q=php2hex&meta=

Op zich een leuke manier om veel afbeeldingen in een script te stoppen maar echt serieus, handig is absoluut anders ;) aangezien een PHP script van bijna een MB toch niet snel te parsen is door PHP!

:)

Niet echt bepaald handig en voegt weinig toe.