Filesystem keuze, bestanden opslaan

[xaban]

Op het moment werk ik aan een project/website, met de tijd zal de website ongeveer 10.000, hooguit 15.000 foto's hosten, waarvan de helft ongeveer 5kb per stuk en de andere helft 50kb zal zijn.

99% van alle verkeer zal read zijn, hooguit 1% write.

Normaal gebruik ik gewoon voor alles ext4, echter vraag ik mij of ext4 wel de juiste keuze is bij duizenden kleine bestanden. Wat raden jullie aan? Of is 10.000-15.000 dermate weinig dat je zo goed als geen verschil zult merken?

Mijn tweede vraag is, alle bestanden in 1 map opslaan of scheiden? Heb je daar in nog performance verschil?

Voorbeeld:
images/original.jpg
images/thumbnal_original.jpg

of:
images/original/foto.jpg
images/thumbnail/foto.jpg

[systemdeveloper]

10-15k is niet veel. Waar je een beetje op moet letten is dat je niet alles in 1 grotere directory knalt. Dat gaat je met grote aantallen bijten en dan is de performance gewoon weg.
Wat wij doen (maar dan heb ik het over meer dan 100miljoen pics) is een subdirectory struktuur maken gebaseerd op de eerste x tekens van een md5 van de bestandsnaam/url).
Dan krijg je een goeie verdeling van je pics en blijf je performance goed.

Wil je het echt goed doen dan pak je een bak met varnish en nginx waar je de images op dumpt. In 1 directory struktuur zet je de originelen en in 1 struktuur zet je de gecachte varianten.
Met wat scripts en rewrite rules kun je dan mooi regelen dat je images bij de eerste aanroep op juist formaat geschaald worden en in de cache subdirs worden gegooid. Deze worden daarna dan zonder overhead door varnish/nginx naar buiten gestampt.
Misschien een beetje werk om op te zetten en niet zo spannend voor 15k pics, maar ja, eens goed opgezet is altijd goed opgezet

[visser]

Op het moment werk ik aan een project/website, met de tijd zal de website ongeveer 10.000, hooguit 15.000 foto's hosten, waarvan de helft ongeveer 5kb per stuk en de andere helft 50kb zal zijn.

99% van alle verkeer zal read zijn, hooguit 1% write.

Normaal gebruik ik gewoon voor alles ext4, echter vraag ik mij of ext4 wel de juiste keuze is bij duizenden kleine bestanden. Wat raden jullie aan? Of is 10.000-15.000 dermate weinig dat je zo goed als geen verschil zult merken?

Mijn tweede vraag is, alle bestanden in 1 map opslaan of scheiden? Heb je daar in nog performance verschil?

Voorbeeld:
images/original.jpg
images/thumbnal_original.jpg

of:
images/original/foto.jpg
images/thumbnail/foto.jpg

Het is geen enorm groot aantal wat je noemt, maar er zou performance verschil kunnen zitten wanneer er inderdaad heel veel bestanden in een directory zitten.
Klassiek ext2, en ook ext3 nog wel hadden daarin bottlenecks (lineaire lijst) , en bijvoorbeeld XFS was er veel beter in.
Ext3 heeft later een tree structuur gekregen die het zoeken in grote directories (>1000 bestanden) wel snel maakt, en ext4 heeft dat ook.
Ik denk niet dat je daar een technisch issue mee zult hebben, en als je front-end gewoon direct de file opvraagt verwacht ik geen performance probleem.

Ik meen wel eens benchmarks gezien te hebben, maar ik kan ze nu niet meteen terugvinden. Wel zag ik een paar natte vinger aanbevelingen die in dezelfde orde van mijn natte vinger gaan . (orde paar duizend per directory)
Als je ook met de gewone commandline tools dingen wilt doen loop je daar wel tegen dingen aan als je veel files in een directory hebt (rm * - too many arguments) , en moet je er met bv xargs omheen gaan werken. Dat staat los van het filesysteem, maar het kan wel hinderlijk zijn.

Als het kan wat de rest van je site betreft zou je dan de files in wat subdirectories willen opslaan :
images/00/img001.jpg
images/01/img101.jpg
images/zz/img123.jpg

Als de filenamen zich niet direct lenen om een redelijke verdeling over subdirectories te krijgen (/var/mail/j/{jansen,jensen,julia} , /var/mail/p/{paping,peters,pietersen } ) kun je een hash functie gebruiken op de filenaam om een subdirectory toe te wijzen.

[Cybafish]

Natte vinger...

..haha sorry kon het niet laten

[xaban]

Wat is het voordeel van Varnish/caching? Dat het direct uit het geheugen wordt gehaald en geen I/O plaats vind op de schijven?

Kan ik niet gewoon een ramdisk aanmaken? Of denk ik te simpel

10-15k leek mij inderdaad ook niet veel, maar misschien wel teveel voor 1 directory.

[systemdeveloper]

Wat is het voordeel van Varnish/caching? Dat het direct uit het geheugen wordt gehaald en geen I/O plaats vind op de schijven?

Dat is het grootste voordeel idd. plus dat het makkelijker is om de hele imageboel op een ander systeem te gooien en resizen e.d. daar te laten afhandelen ipv. op je main site.
Maar met 10-15k images en een paar k bezoekers per dag is het wellicht wat overkill.
Als het echter mogelijk is dat het over 1-2 jaar 100k images zijn, dan is het wel slim om daar op voorhand al rekening mee te houden.

[xaban]

Dat is het grootste voordeel idd. plus dat het makkelijker is om de hele imageboel op een ander systeem te gooien en resizen e.d. daar te laten afhandelen ipv. op je main site.
Maar met 10-15k images en een paar k bezoekers per dag is het wellicht wat overkill.
Als het echter mogelijk is dat het over 1-2 jaar 100k images zijn, dan is het wel slim om daar op voorhand al rekening mee te houden.

Nee, 10-15k maximaal, hooguit misschien 20k, maar meer ook niet. Maar ik kan dus ook gewoon een ramdisk opzetten? Dan heb ik namelijk geen extra software nodig.

[The-BosS]

Nee, 10-15k maximaal, hooguit misschien 20k, maar meer ook niet. Maar ik kan dus ook gewoon een ramdisk opzetten? Dan heb ik namelijk geen extra software nodig.

Niet helemaal, nginx/varnish hebben een veel beter engine (source) die request veel vlugger verwerkt dan bvb apache en tevens ook nog minder ram per request verbruikt. Je moet dus het totale plaatje bekijken, overigens kun je nginx ook draaien zonder apache er achter en dan heb je helemaal geen extra software nodig.

[visser]

Wat is het voordeel van Varnish/caching? Dat het direct uit het geheugen wordt gehaald en geen I/O plaats vind op de schijven?

Kan ik niet gewoon een ramdisk aanmaken? Of denk ik te simpel

10-15k leek mij inderdaad ook niet veel, maar misschien wel teveel voor 1 directory.

Veel read is niet waar een ramdisk veel (extra) voordeel geeft, Linux houdt zelf al feitelijk alle geheugen waar niks anders mee te doen valt in gebruik als VFS cache. (dus onafhankelijk van welk filesystem daar onder zit).
Zolang je geen andere dingen doet die veel geheugen rond laten lopen verwacht ik dat de VFS laag zich prima als ram cache gedraagt.

Een deel van je ram gebruiken als ramdisk voegt daar weinig aan toe, bovendien moet je dan tooling bouwen om je files van disk naar ramdisk te kopieëren, je ramdisk sizen etc.
Dat gaat automatisch al in de VFS layer cq met een reverse proxy ervoor .

nginx is gewoon heel erg efficient in het uitserveren van statische files.

Een expliciete ramdisk heeft nut als je heel veel writes hebt en de applicatie die de writes doet daar een volledige FS transactie van wil maken (fsync), terwijl je beter weet en een minder frequente sync naar non-volatile storage ook voldoende is. (cronjob elk vijf minuten ). Een ramdisk gedraagt zich naar de applicatie toe puur als een extreem snelle disk.

[systemdeveloper]

Sidenote: Een ramdisk is ook wel handig als /tmp als je database veel tijdelijke bestanden maakt.

[visser]

Sidenote: Een ramdisk is ook wel handig als /tmp als je database veel tijdelijke bestanden maakt.

Dat is zelfs gebruikelijk genoeg dat op Solaris /tmp sinds lang op een 'tmpfs' filesystem gemount was, een filesystem dat in virtual memory leeft. (en dus geen reboot overleeft) .
Je ontdekt het soms als je /tmp gebruikt om 'even' een grote file te parkeren ..
Linux kan het ook, maar heeft het niet default zoals Solaris.

[boomhut]

Ik zelf heb een website waar 30.000 foto's worden gehost. Waar de Thumbnails rond de 5kb en origineel rond de 500kb groot zijn.
Deze zijn in gedeeld in twee mappen: /images/origineel/*.jpg en in /images/Thumbnail/*.jpg
Dit alles draait op een virtuele webhosting.
Zoals jij aangeeft 99% read 1% write. Alle 30.000 verwijzing van de afbeeldingen staan in de mysql-database en de website is erg snel. (Met nog erg slordige php code) Nooit last gehad van traagheid of andere problemen. Als je met een ftp of sftp programma de map wil inlezen is het wel traag.
Wat ik persoonlijk nooit doe

Website trekt ongeveer 100 tot 200 bezoekers per dag. Piek 1000 per dag.
Dus kan prima op een ext4.


Edit: spelfouten.