Archief - performantie submappen

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
G

Gogeta

Legacy Member
stel je hebt een site met deze structuur:

/index.php bevat 500tal thumbnails met links naar mappen (zie verder)

/thumb/thumb1.jpg
/thumb/thumb2.jpg (dit 500 tal keer, zijn de thumbs die je ziet in in /index.php)

/1/index.html (met enkel de grote versie van thumb1 in <img> tags )
/2/index.html etc etc

----------------------------------------

Ik ken iemand die zo werkt, nu is de vraag is dit qua performantie negatief? vanwege het aantal submappen

Persoonlijk zou ik eerder werken met:

/index.php
/thumbs/allethumb.jpg
/images/alleimages.jpg

en dan index.php?id=17 en <img src="/images/'.$id.'.jpg">


----------------------------------------

Beter nog denk ik? Klikken ze op een thumb dan opent zich een lightbox en met een ajax call de grote image tonen ?


Dusssss, wat is het beste en ook, waarom ?
b

blackrabbit

Legacy Member
Waarom zou 1 map trager of sneller zijn dan meerdere?
G

Gogeta

Legacy Member
kweetni, drmee da ik het vraag hé :)

About the current setup:

At present, the pictures on the first page of the site each have their own folder with an index.html file inside. I did this so that you could go to http://url.com/40 and it would take you to the image without having to see the file extensions or have long urls so that it would be easy & short to use.

Also, I'm noticing intermittent timeouts and slow loads, I'm not sure if my setup (over 500 folders in the root of the server) is causing them?
-

-BVR-

Legacy Member
Ik zou het zelf nooit doen. Als je geen .jpg extensie wilt, kan je dat volgens mij toch op een andere manieren oplossen... Maar bon.
a

adrianhates

Legacy Member
Gogeta zei:
Beter nog denk ik? Klikken ze op een thumb dan opent zich een lightbox en met een ajax call de grote image tonen ?
Dusssss, wat is het beste en ook, waarom ?
Klik om te vergroten...


Wat heeft dit met AJAX te maken? Als je een thumb zet op de pagina als link die een lightbox opent met de image gegeven in de href attribuut ( de grote image ) , wordt die toch ook pas geladen als je er effectief op klikt? :)

Het aantal submappen gaat de performantie niet doen dalen , enkel uw schijfruimte :p Want ne map is gewoon een bestand dat als map aangeduid wordt :p Ook uw eigen efficiëntie gaan dalen denk ik :)
D

Disa

Legacy Member
Ik weet niet of het echt relevant is, but here goes.
De performantie is wel afhankelijk van het aantal files/folders in een map. Zet maar eens 2000+ files/folders in een foldertje en kijk eens hoe goed Finder/Explorer er mee omgaat. 500 lijkt mij echter nog redelijk en zou dus geen al te groot probleem mogen zijn.

Wat wij deden voor content waar we niet zeker van wisten hoeveel het er konden zijn was een soort hashing structuur in te bouwen. Dit kon
  • time based zijn: /2012/01/08/13/image-2012-01-08-13:02.jpg
  • sha1 van de filename en dan iedere 2 chars gebruiken als folder: sha1("image-2012-01-08-13:02.jpg") -> "0d7088233108e9e615e9aac08710aa5154b21b3c" -> /0D/70/88/23/image-2012-01-08-13:02.jpg
G

Gogeta

Legacy Member
Bedankt voor de input Disa, erg doordachte methode lijkt me,
ik betwijfel dat het er 1000 gaan worden... dus dit lijkt me ergens een beetje overkill?

@adrianhates, de reden voor de ajaxcall is dat je dan niet moet verwijzen naar een url.com/20/index.html maar gewoon rechtstreeks de image kan oproepen. Ok granted dat er op die index.html niet veel info staat buiten een <img> en een advertisement, maar het is toch 2-3kb minder per view (doctypes, headers etc?).

Ik spreek hier over een site met (raar maar waar) 13k uniques/dag en 40k views/dag, 40*3kb= 120mb trafiek minder/dag 3.6gig/maand
G

Gogeta

Legacy Member
Nu dat ik er bij na denk, dan is de omslachtige mappen-aanpak misschien wel beter voor SEO? hoofdpagina toont immers 400+ interne links naar andere paginas, terwijl de include methode eerder 1 pagina weergeeft?
b

blackrabbit

Legacy Member
Disa zei:
Ik weet niet of het echt relevant is, but here goes.
De performantie is wel afhankelijk van het aantal files/folders in een map. Zet maar eens 2000+ files/folders in een foldertje en kijk eens hoe goed Finder/Explorer er mee omgaat. 500 lijkt mij echter nog redelijk en zou dus geen al te groot probleem mogen zijn.
Klik om te vergroten...
Er is een verschil tussen weergeven wat er in een map zit (in bvb explorer) en bestanden doelgericht opvragen he.


Er kan eigenlijk sowieso geen eenduidig antwoord op gegeven worden, vermits heel vaal afhangt van het gebruikte file system. Maar in ieder geval: 500 items zou geen enkel probleem mogen geven.

De oorzaak van de timeouts moet elders gezocht worden lijkt mij.
D

Disa

Legacy Member
blackrabbit zei:
Er is een verschil tussen weergeven wat er in een map zit (in bvb explorer) en bestanden doelgericht opvragen he.
Klik om te vergroten...

Niet echt. Een folder (op linux) is niet veel meer dan een lijst met <filename, inode> tuples. En je hebt de inode nodig want die bevat de nodige metadata en pointers waar de file precies op disk zit. [1]

Telkens je naar een file (of folder) vanuit folder A gaat, zal je FS driver folder A zoeken, de lijst met tuples overlopen tot hij de correcte heeft gevonden. Nu heeft hij de bijpassende inode en kan die dus gebruiken om (een pointer naar) de file terug te geven.

Dus zelf al heb je het volledige pad, je moet de lijst aflopen.

Om toch maar ontopic te blijven:
Het lijkt me sterk dat het daar aan zou liggen. Zoals BlackRabbit zegt, ik zou het probleem ergens anders zoeken.

[1] inode - Wikipedia, the free encyclopedia
G

Gogeta

Legacy Member
BramVroy zei:
Ik zou het zelf nooit doen. Als je geen .jpg extensie wilt, kan je dat volgens mij toch op een andere manieren oplossen... Maar bon.
Klik om te vergroten...

Dank u voor die "andere manieren"-methode met ons te delen...
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan