Wall -> cache (Кеширование постраничного вывода)

maragon

Новичок
Думал, думал, в итоге не надумал.
Есть стена пользователя - хранится все в бд (mysql).
Как правильно можно её закешировать в файловую систему дабы потом можно было легко манипулировать данными (удалить/обновить/добавить)?

Первый мой вариант был таков, при загрузке страницы пользователя кидаем запрос в кэш, если его нет, то кидаем запрос в бд и создаем кэш, после берем данные из кэша (выводим на экран все содержимое, т.е все сообщения). Но это без постраничной навигации. Как быть с ней? Как правильно организовать алгоритм?

Подгружать сообщения стены в дальнейшем хотелось бы ajax'ом при прокрутке страницы.
:rolleyes:
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
all we know's just there's another cache for the Wall :D
maragon, ты хочешь неправильного - выводить надо из базы, надо оптимизировать запросы, файловый кеш быстрее не будет
 
Последнее редактирование:

Adelf

Administrator
Команда форума
Самый главный совет: не оптимизируй пока не начнет тормозить. Сам был свидетелем проекта, где все оптимизировали да оптимизировали под большие нагрузки, а в итоге нагрузки были такие смешные, что в итоге куча времени была убита совсем не на то.
Второй совет, вторые страницы редко смотрят. Кешируй только первую. Главное, не забыть сбрасывать когда появляются новые записи ;-)
 
  • Like
Реакции: AmdY

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Adelf, я был свидетелем 100 таких проектов, и всего 3х, которые потребовалось оптимизировать
 

A1x

Новичок
если отвлечся от целесообразности то для постраничного вывода можно использовать кеширование с тегированием (taggable cache) т.е. все страницы при кешировании помечаются некоторым тегом, при изменении содержимого базы все элементы кеша сбрасываются по этому тегу. Можно не изобретать велосипед а взять готовый движок с поддержкой тегирования и файловым адаптером (если обязательно хочется хранить кеш в файлах). Например можно посмотреть Zend\Cache
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
A1x, Суп. Надо. Есть. Ложкой!

это плохая рекомендация потому что чтение 10ти файлов выполняется дольше, чем выбока 10ти записей из таблицы по ключу с сортировкой и лимитом,
к тому же инвалидация файлового кеша, разбросанного по иерархической структуре, будет непростой задачей - такой кеш не "сбрасывается", это куча дисковых операций поиска-записи, которые при конкурентности положат систему
 
Последнее редактирование:

A1x

Новичок
grigori, японцы едят палочками. я же написал "если отвлечся от целесообразности", про целесообразность тут все правильно написали
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
A1x, перечитай пост Фаната еще раз на тему защиты прав,
ты советуешь как отстрелить себе ногу,

если отвлечься от темы, файловый кеш в фреймворках - ужос,
им можно пользоваться только для тестирования кеширования, чтобы наглядно видеть какие записи в кеше создаются
 
Последнее редактирование:

AmdY

Пью пиво
Команда форума
grigori, японцы едят палочками. я же написал "если отвлечся от целесообразности", про целесообразность тут все правильно написали
японцы пользуются как раз очень удобными ложками для супа, вместительные такие. у них как раз целесообразные столовые приборы, большие куски таскаются палочками, а бульён хлебается ложкой.

Потому и со стеной такое же правило, сразу делаешь без оптимизации, затем уже думаешь о кэше или денормализации, а уж когда и это заканчивается думаешь о гибридных стораджах.
 

A1x

Новичок
Вот я и предлагаю вместо изобретения своих файловых велосипедов изучить общепринятые практики и инструменты кеширования, позволяющие кроме всего прочего переключать бекэнд легким движением с файлов на APC, Memcache, etc. Это и есть ложка, про которую ТС не знает. Еще не мешает посмотреть задействован ли mysql query cache, его может вполне хватить. Но иногда структура базы настолько запущена что проще закешировать чем оптимизировать запросы
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а в mongo is web scale можно хранить связанные записи, а в AWS можно положить в S3, и по реке поплывет кирпич, деревянный как стекло :)
 
Сверху