search

matthiask / django-imagefield

You should probably use this image field instead of Django's built-in models.ImageField.
https://django-imagefield.readthedocs.io
BSD 3-Clause "New" or "Revised" License
100 stars 10 forks source link

Pip package #1

Closed serdargkaya closed 6 years ago

serdargkaya commented 6 years ago

Hi matt,

Can u release a pip package ? Before that let me test this changes if you haven't.

serdargkaya commented 6 years ago

Btw it is good practice to creating folder for every image ?

matthiask commented 6 years ago

Hey, I'm currently waiting for some feedback on the image name changes because I really only want to change this once if possible :)

Apart from this, 0.2.4 works fine. Upgrading to 0.3 will require rerunning manage.py process_imagefields --all unfortunately, but that cannot be avoided when changing the file name generation.

Regarding folders: The idea is to avoid putting all images in the same folder, because (at least some) filesystems (in at least some configurations) on linux scan folders sequentially, meaning that if nginx serves a file, it has to scan through hundreds or thousands of entries to find the file which may become a performance problem.

https://stackoverflow.com/questions/13046714/optimal-number-of-files-per-directory-vs-number-of-directories-for-ext4 https://stackoverflow.com/questions/8238860/maximum-number-of-files-folders-on-linux

I'm working on a site with more than 100'000 images. The current fan-out of xx/xx/* would create 16^4 = 65536 bins. Maybe that is a bit too much.

Maybe I could do what git does, and use a fan-out of xx/*.

matthiask commented 6 years ago

I should have checked first :) I already got some feedback, and released 0.3 with a small change to the filename hashing method.

serdargkaya commented 6 years ago

@matthiask For seo it is good practice to keep image name. So this change needed to happen one way or another. I tested too looks good. Thanks.