Зачем нужен кэш?

[KillDead]

ППЦ. Одно сообщение грамотное от sidxx55
Кто в лес, кто по воду

грамотное оно то грамотное, остальные тоже нормальные, правда подробностей таких нет. Но ТЗ вроде спросил, что лучше - хранить кэш в базе мускула или в файлах. А ему ответили что лучше всего использовать средства сервера, доп компоненты, кэширования сорца да и вообще оперативную память.
На моей памяти была статья- в ней аватарки хранили не файлом, а в базе мускула и он проводил кучу тестов и показал что это быстрее. Может он и человек умный но вроде тот ещё долбоёб (все тесты были на винде 7). Ещё обсуждал с парой человек, в итоге пришли к выводу - бред это всё.
Я, если честно не сталкивался с таким и могу лишь предполагать.
Но ближе к теме. Тут ситуация другая- мы храним не файлы а какой то кэш, к примеру вывод новостей 1-1000000. Погуглил, нашёл пару статей- к примеру Для просмотра ссылки Войди или Зарегистрируйся Хотя не совсем адекватно как мне кажется. Тут действительно я теряюсь в точном определении победителя. С одной стороны - файловая система, это намного менее затратнее по поиску, но при миллионах кеш файлах - хз. Но и мускул забить лямом немаленьких данных, тоже мне кажется не особо айс. А генерал чтолибо в чате отвечал?

 

[Горбушка]

Ну давайте я тоже порассуждаю...

а) Утечка времени на подключение БД и прочее при использовании MySQL отсутствует, т.к. мы изначально подключаемся к БД для работы CMS и отключаемся только в самом конце файла
б) При наличии индексов MySQL выполняет поиск намного быстрее, чем выполняется поиск по файлам
в) Помимо чтения нам постоянно нужно записывать обновления и дополнения этого кэша, а это жопа для файловой системы, но привычная операция для MySQL...

Итог, хранить в MySQL кэш в ряде случаев выгодно, хранить кэш в файлах выгодно очень редко и есть смысл только если другие средства кэширования уже не справляются... В случае наличия nginx или Varnish использовать кэш глупо, ибо эти системы куда эффективнее справляются с задачей кэширования.

В результате, я понимаю весь топик так:
1) Все данные храним в MySQL
2) Сложные в обработке данные храним в кэше в MySQL
3) Данные, не требующие обработки храним в кэш в ОЗУ

Т.е. делаем примерно так же, как все современные CMS, но кэш делим на 2 места хранения - память и MySQL для упрощения обработки этого кэша...

Кроме того, активно используем то, что даёт нам хостинг - nginx или Varnish, но это уже на совести хостера...

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

 

[invader]

invader

поясни пожалуйста о чём ты
в стартовом вопросе ТС нет ни единого намёка на кэширование байткода php

сообщение sidxx55 подробно раскрывает тему разгрузки php и "apc" который помимо собственно кэшера байткода ещё имеет и встроенную возможность кэшировать любые переменные в том числе полученные из mysql (именно в этом контексте его упомянул я)

Я о том, что топик как раз не о администрировании серверов.

зачем вообще нужен кэш в CMS?

Вот и кто в лес, кто по воду. sidxx55 хоть что то подробно расписал.
Особенно "порадовало" это:

А попробуйте кеш хранить не в файлах, а в memcache. Удивитесь скорости работы по сравнению с файлами.

Почему или.. или...
Я сравнил и давно. Удивитесь в зависимости от... а вот тут куча вариантов.
memcache нафиг, если контента кот наплакал.

 

[sidxx55]

Вики поможет, с практикой в конце концов. Так или иначе запросы рождаются не из воздуха, O_nix, тема для чего нужен кеш? => для чего нужен кеш CMS, как тут без кеширования байт-кода

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

 

[invader]

Ну давайте я тоже порассуждаю...

а) Утечка времени на подключение БД и прочее при использовании MySQL отсутствует, т.к. мы изначально подключаемся к БД для работы CMS и отключаемся только в самом конце файла
б) При наличии индексов MySQL выполняет поиск намного быстрее, чем выполняется поиск по файлам
в) Помимо чтения нам постоянно нужно записывать обновления и дополнения этого кэша, а это жопа для файловой системы, но привычная операция для MySQL...

Итог, хранить в MySQL кэш в ряде случаев выгодно, хранить кэш в файлах выгодно очень редко и есть смысл только если другие средства кэширования уже не справляются... В случае наличия nginx или Varnish использовать кэш глупо, ибо эти системы куда эффективнее справляются с задачей кэширования.

В результате, я понимаю весь топик так:
1) Все данные храним в MySQL
2) Сложные в обработке данные храним в кэше в MySQL
3) Данные, не требующие обработки храним в кэш в ОЗУ

Т.е. делаем примерно так же, как все современные CMS, но кэш делим на 2 места хранения - память и MySQL для упрощения обработки этого кэша...

Кроме того, активно используем то, что даёт нам хостинг - nginx или Varnish, но это уже на совести хостера...

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

Вот оно!
Грамотное распределение нагрузки.
И тут нет единого совета. Зависимость от многих факторов.

 

[CAPAXA]

А вот зачем кэш нужен в CMS? Ведь HDD, т.е. файловая БД, работает медленнее, чем MySQL... Я могу предположить, что кэширование нужно очень тяжёлым и редко изменяемым запросам - к примеру статистики сайта... Её достаточно обновлять раз в сутки, а в кэше хранить готовый ответ MySQL... Но современные CMS кэшируют всё подряд... Есть ли в этом смысл?

Берем коробочную версию ЦМС, например Джумлу и делаем опыт с тремя факторами.
1) Без кеширования
2) Кеширование с использованием файловой системы
3) Кеширование в memcache/xcache

И смотрим время выполнение скрипта и потребленные ресурсы.
Все остальное - кеш байткода, nginx и т.д. ускоряет, но изначально в постановку вопроса не входит.

Выводы думаю сделаете сами.

 

[sidxx55]

А) запрос не может быть рожден из воздуха, т.е. обращение происходит на языке пхп, ... мысленно к нему не получиться обратиться чтобы он работал быстрее
Б) CMS я полагаю состоит из н кол-ва пхп файлов, через которые осуществляются запросы
С) ПХП работает с байт кодом тут уж хоть как запляши
Д) почему есть понятия кешеров в пхп? <= потому-что есть узкие места (компиляция), где потери можно компенсировать
Е) Ну уж полагаю тут постановка вопроса проекта более чем сама Вики
F) От теории может пора уже переходить к практике, а то сколько людей столько и мнений.

 

[o_nix]

invader
ну если уж на то пошло то что бы поставить любой кэшер байткода надо иметь права root на сервере
так что администрировать придётся в любом случае

моё мнение по сабжу кэширование в файлах морально устарело - есть куда более производительные решения и всё по большей степени сводится не к переписыванию CMS а к настройке сервака под эту конкретную CMS

apc - это универсальное решение которое установить проще некуда и встроенно в php самими разработчиками

моё мнение

1. в CMS кэшируем узкие места с использованием apc
2. Front-end - обеспечивающий кэширование в статику, отрубая всю остальную цепочку

ели проект размеров с wiki - то nginx кэширование в файлы, тк в оперативку просто не влезет )))))))))))))

 

[invader]

o_nix - я отталкиваюсь от: клиент пользуется шаред хостингом.
Файловый - Поддерживается везде. Ещё бы не поддерживался.
Memcache - Поддерживается почти везде
Xcache - Редко
eAccelerator - Редко
Shmop - Не встречал на шаред
APC - Поддерживается очень часто