Открыть список
Как стать автором
Обновить

Комментарии 19

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

я видел человека, который как-то сделал файл-хостинг без базы данных — все хранилось в генерируемых php файлах, в итоге у него валились винты

Скорость работы файлового кеша будет очень сильно зависеть от быстродействия жестких дисков и активности файловых операций (особенно актуально, если используется shared-хостинг). Во всяком случае, RAM быстрее RAID'ов.
Похоже Вам неизвестно о Page cache
угу, вот только если файлов станет несколько десятков тысяч, или под полсотни тысяч, да еще и мелких…
цифр не дам, но у меня когдато такое было, мемкешед (локальный) был намного эффективнее.
Есть еще и другая проблема, когда количестве кешей на сайте может стать настолько высоким, что на сервере станут кончаться уники )
Согласен. Если кеш не помещается в свободную оперативку, то лучше memcached. Он хоть будет удалять старые объекты. А на файлах без atime такого не сделаешь.
думаю, кому-то пригодится. для мелких проектов.
но с другой стороны зачем на мелких проектах кеш?
Есть мелкие проекты с долгими вычислениями (или кучей пользователей). Там кешировать как раз хорошо.
Но доля правды в этом посте есть… Есть проект с достаточно большой посещаемостью (примерно 40-50 тысяч пользователей в сутки, которые проводят на сайте от 15 минут до целого дня) который полностью работает на файлах и не использует ни одной БД.
Если делать файловый кеш, то хорошо бы сразу применить кеш-контроллер с концепцией фронтэнд-бекенд, как например в Zend Cache. Фронтэнд — это постоянный интерфейс для программиста, бекенд может быть любым (файлы, memcached, APT, XCache...)
если будет много записей, а не одна, то всё равно обращения к винту будут (на запись), что будет много медленнее записи в оперативку.

А вообще у нас пока у самих рамдиск и на него файлокэши сохраняются. Но собираемся переходить на memcache — оно как-то получше в свете наших дальнейших развитий выглядит.
Если под линуксом, то проще ли использовать tmpfs в оперативке.
Работать можно как с обычными файлами, и ничего выдумывать не надо.

tmpfs хорош для коротко живущих файлов. Иначе только минусы.
при кеше в файлах я этот вопрос решал нежестким временем жизни кеша.
например так:
$livetime = 600 + mt_rand(0, 300); // время кеша от 600 до 900 секунд
т.о. тяжелые запросы в БД генерили только 1-3 юзера, при посещении 300 запросов в сек.

в memcached так не получится, т.к. время жизни задается сразу и его нельзя поменять,
но можно выкрутиться, например считать кеш старым не по времени, а по вероятности:
$isCacheValid = mt_rand(1,1000) == 500;
точнее так:
$isCacheValid = mt_rand(1,1000) != 500;
write_cache($file, $data = "") {
file_put_contents($file, "");
}

read_cache($file) {
include($file);
return $data;
}

минус время на сериализацию и десериализацию :)
чиорд… в функции записи было var_export($data) и открывающий-закрывающий пхп-теги :-\
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.