Влияние количества файлов в папке на скорость

[Сенсей]

Влияние количества файлов в папке на скорость

Делаю функцию для юзеров что бы могли загружать фотки ...

В базе буду держать имя файла ....

Все файлы кидать в папку photos и потом показывать по имени файла взятого с базы...

Ну здесь таблов нету... вопрос скорее теоретический....

Пример: Windows - есть папка в которой 6000 файлов... и визуально видно что она раз в 20 медленнее открывается чем папка с пару десятком файлов...

Так вот не будет ли влиять на работу скрипта количество файлов в папке?

 

[jonjonson]

Я бы не стал держать 6000 файлов в одной папке. Но в данном случае, раз ты не получаешь список файлов в папке (это то что происходит под Windows, когда ты открываешь папку), а обращаешься к отдельному файлу (беря его имя из БД), то тормазов быть не должно.

 

[Найч]

Так вот не будет ли влиять на работу скрипта количество файлов в папке?

Будут. Когда их тысячи. Но слегка.
В винде ты смотришь папку через файловый менеджер и большая часть времени у него уходит на формирование картиночек и прочих радостей к файлам, а не на чтение их имен.

 

[sky2k4]

Originally posted by Найч
Будут. Когда их тысячи. Но слегка.
В винде ты смотришь папку через файловый менеджер и большая часть времени у него уходит на формирование картиночек и прочих радостей к файлам, а не на чтение их имен.

будут тормоза
под юниксах есть фаловая система reiserfs как раз для этих целей, снимает этот недостаток

можно воспользоваться алгоритмом с общей идеей /images/a/ab/abc/abcdefg.jpg

 

[varan]

можно воспользоваться алгоритмом с общей идеей /images/a/ab/abc/abcdefg.jpg

Угу. Только лучше брать $filename = md5($filename). Тогда равномернее получится, а то вдруг у него все картинки начинаются на aaaa

 

[neko]

за равномерность отвеачет файловая система, а не ваши доморощенные алгоритмы

 

[TuBu]

neko

Это как?

 

[Ilya]

имхо jonjonson абсолютно прав.
ведь список файлов при обращении напрямую файлу ты не получаешь.

 

[SiMM]

Автор оригинала: Ilya
ведь список файлов при обращении напрямую файлу ты не получаешь.

Ты так думаешь? Интересно (рассматриваем ситуёвину с FAT, с остальными FS абсолютно не знаком), каким (отличным от просмотра полного пути) образом определяется, с какого кластера начинается некоторый определённый файл? Ситуацию с кэшированием можно опустить (ибо она может быть реализована независимо от FS и имеет к заданному вопросу лишь косвенное отношение).

 

[Profic]

Люди, а вы не задумывались над тем, что для того чтобы получить доступ к файлу нужно получить их список? Не весь конечно, а до совпадения. Правда, поиск закончится задолго до конца списка (чтение), но может и закончится по прочтении всего списка (запись нового файла).
Из своего опыта: на FAT32 если в каталоге больше 500 файлов, то это начинает существенно тормозить активную работу с данным каталогом. На моей задаче (создание кучи маленьких файлов с последующим их чтением) разница времени выполнения скрипта до и после разделения файлов по каталогам получалась ~10 раз

 

[Ilya]

Автор оригинала: SiMM
Ты так думаешь? Интересно (рассматриваем ситуёвину с FAT, с остальными FS абсолютно не знаком), каким (отличным от просмотра полного пути) образом определяется, с какого кластера начинается некоторый определённый файл?

оффтоп конечно..
но если так судить то получается чем больше у нас на жестком диске файлов и каталогов тем он медленнее работает?
ведь чтобы узнать "полный путь" надо сделать точно такие же действия системе?

 

[SiMM]

Ilya, это не рассуждения, это факты. Опять же прошу заметить, относительно FAT'а. И кстати вывод несколько неверный - прочти пост Proficа. Грубо говоря, когда всё сложено в один каталог, поиск файлов будет занимать линейное время, когда файлы раскиданы определённым образом по подпапкам, можно добиться меньшего времени поиска начала файла (собственно, только это от каталогов в FAT и требуется - найти начало файла).

 

[sky2k4]

varan
я ж написал - с общей идей, алгоритм равномерного распределения файлов можно и самому придумать

neko
за равномерность отвеачет файловая система, а не ваши доморощенные алгоритмы

для это цели подходит reiserfs в который применяются b-trees и хэши для поиска фалов и масса всяких полезностей
Но это хорошо,если у тебя dedicated на котором сам хозяин, но на большинстве серверов стоят ext2|3
Эти "доморощенные" алгоритмы применяются во многих крупных проектах

 

[neko]

fat32 и ext3 имеют столько же общего сколько, прости господи, профик с балериной

Из своего опыта: на FAT32 если в каталоге больше 500 файлов, то это начинает существенно тормозить активную работу с данным каталогом.

fat32 устроен так, что там по определению будет много сиков.
500 файлов, не влезут в один кластер
и сами их названия если они писались не на чистый диск будут валятся в разных углах дисках скорее всего

ext хранит ссылки на соседние inodes, а не втупую цепочки кластеров, уже одно это сильно ускоряет такие операции

рейзер
оно конечно хорошо
но места жрет...

 

[Кром]

Кстати, о поиске:
http://phpclub.ru/talk/showthread.php?s=&threadid=35405

 

[si]

рейзер
оно конечно хорошо
но места жрет...

в цифрах можно ?

 

[neko]

Кром
вопрос еще в том
что люди подразумевают по словом "много"
у приличной ос есть кеш на это дело

тут вот написана цифра 6000
6000 в кеш влезет при первом открытии директории и спокойно проживет там до ребута

-~{}~ 11.01.05 22:56:

si
коротко:
reiserfs это disk performance vs. cpu & storage efficency

на практике это выливается в сильную зависимость от настроек файловой системы (notail) и реальной структуры хранимых файлов.

например хвосты
у рейзера стандартный размер блока 4кб
если хвосты не использовать, все что осталось в блоке свободным после хвоста -- пропадает.
т.е. если у тебя 1К файлов по килобайту, они займут 1мб. и еще 3мб ты потеряешь просто так.
с хвостами -- увеличишь фрагментацию.

фактическая "потеря" места зависит очень сильно от того как диск используется. и поскольку рейзер оптимизирован именно под мелкие файлы и чаще всего для их хранения и используется (а иначе есть например xfs), то "потери" бывают достаточно большими по сравнению с тем же ext3

или btree -- это чудестно, потому что драматически уменьшает кол-во сиков
но грузит cpu....

afaik в reiser4 есть какие-то улучшения в области расходуемого места

 

[si]

например хвосты
у рейзера стандартный размер блока 4кб
если хвосты не использовать, все что осталось в блоке свободным после хвоста -- пропадает.
т.е. если у тебя 1К файлов по килобайту, они займут 1мб. и еще 3мб ты потеряешь просто так.

разве другие FS не имеют такой особености ?

 

[neko]

помоему ответ очевиден, нет?
некоторе "другие" имееют, неокоторые "другие" не имеют
или ты хотел сказать все остальные?

 

[si]

некоторе "другие" имееют, неокоторые "другие" не имеют
или ты хотел сказать все остальные?

ок,
какие fs из мира *nix имеют аналог tail ?
какой размер блока у ext3/2, xfs, jfs ?

-~{}~ 12.01.05 18:38:

PS. недавно тестил разные FS на приличном железе (RAID 0+1 из 8 scsi дисков 15k rpm) при помощи dbench.

jfs показывает стабильно самое низкое быстродействие, но падение при увеличении клиентов с 10 до 1000 у нее минимальны, а ... думал было написать дальше. но проще оформить результаты, попробую сделать это на днях ...

raw данные тут http://si.infonet.ee/test.tgz