Правильная настройка кэширования

Спасибо. То есть если скрипты не настроены на взаимодействие с memcached, то он не работает и не имеет смысла?

Да, без взаимодействия с ПХП он бессмысленен.

memcached для кластеров. Для одного единственного сервера с ним медленнее чем без него.

Да ладно

Может путаница из за того что есть

кеш сервер Memcached и классы php для доступа к нему

$cache = new Memcache; #Для одного единственного сервера

и

$cache = new Memcached();# а тут есть метод $cache->addServers()

Имя второго совпадает с именем кеширующего сервера.

Мое мнение, для принятия решения - учесть время коннекта + конкуренцию за оп.память (она сейчас недорогая, поэтому все любят ее юзать - и Memcached , и опкеш, и субд туда же)

У Вас есть сомнения что при достаточном количестве памяти тип хранения кэша "файлы" быстрее (один сервер) ?

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

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

На практике, насколько я понимаю, если раздача статики происходит через CDN - кэшировать её на стороне сервера не имеет смысла. Если это Wordpress, да и вообще любой кэш на уровне CMS - он помогает только до определённых пределов. Тут есть такое, что у сайта могут быт миллионы страниц, и создавать кэш для страниц, которые запрашиваются крайне редко - бывает даже накладнее, чем отдавать их без кэширования.

Использование PHP.Opcache и прочих акселераторов - весьма и весьма не однозначно. Вообще, все эти акселераторы кэшируют опкоды PHP в памяти, время кэширования, размер кэша и всё остальное - тоже в общем-то можно долго и много настраивать, однако следует учитывать, что производительность очень сильно зависит и от версии PHP и начиная с PHP7, как правило, рекомендуется использовать PHP APC, вместо других способов кэширования. Обычно этого достаточно.

Вообще же, кэш на уровне CMS имеет смысл выключать полностью, особенно, когда в качестве веб-сервера используется Nginx и PHP-FPM. Непосредственно Nginx (да, на самом деле, и апач так умеет) имеет продвинутые режимы кэширования. Например, запрашиваемая страница превращается в статику, и отдаётся уже без участия PHP-интерпретатора: до него запрос просто не доходит: весьма круто снижает нагрузку. Но как быть с динамическим контентом? И это тоже решается, т.к. сама CMS может подавать сведения для Nginx, что вот, мол, эту страничку кэшировать не надо (Cache control). ВОт статейка на тему: должна пролить свет лучше, чем я тут объясняю: https://ruhighload.com/Кэширование+статики+и+cache-control

Собственно говоря, вывод такой: при правильной настройке серверного окружения использовать внутренние стандартные плагины для кэширования в CMS - не оптимально: при правильном подходе лучше сварганить плагин, который будет работать с Nginx и использвать для кэширования страниц его. Кэширование php-opcache и подобные - да, желательны. Кэширование статики на стороне CDN - ну, только елси используется CDN: этопросто ещё один уровень кэширования. Следует учитывать, что непосредственно CDN обычно предназначен не столько для кэширования и снижения нагрузки на сервер, сколько для более быстрой раздачи контента конечному клиенту, где бы он ни находился (из наиболее близкой точки).

Многие CMS имеют проблемы спроизводительностью из-за кривых тем оформления и/или плагинов. Бывает так, что проявляется огромная нагрузка на MySQL, делаются большие выборки и всё это потом отдаётся перевариваться в PHP. Для PHP же сериализация данных - весьма и веьма затратная операция. Так вот, если какие-то скрипты выполняются долго по времени - следует посмотреть, какие запросы выполняет MySQL, с какими объемами данных работает PHP. Мне встречались случаи, когда выборка из MySQL 12 млн строк передавалась в PHP и он начинал задыхаться, ради отображения самых популярных статей в вордпрессе.

Оптимизация MySQL, как правило, сводится к тому, чтобы вся БД влезала в ОЗУ и в правильной расстановке буферов. Плюс если больше селектов - тогда переезжают на MyISAM, если не нужна транзакционная целостность. В случае, если трафик MySQL очень большой, а так же достаточно большая БД - имеет смысл отключать кэширование MySQL и переписывать скрипты, для того, чтобы использовался Memcached, вместо кэширования мускула. Но всё это жутко индивидуально для каждого проекта.

В общем же случае следует использовать как можно меньше сущностей и создавать максимально низкое количество точек отказа. Особенно не желательно дублировать функционал компонентов системы, к примеру, с кэшированием. Кроме того, кэширование статики (я не знаю, подменяет ли CDN заголовки) в ISPManager галочкой - означает лишь кэширование на стороне браузера. Обычно, при не сильно большом трафике это не снижает нагрузку на сервер никак, это лишь позволяет браузеру клиента повторно запросить содержимое без запроса к серверу. Кроме того, дефолтные правила не всегда охватывают всякую экзотику, которая может использоваться. Например, .woff, .webp, .svg - часто из стандартных правил исключены.

Если задача не снизить нагрузку на сервер, а оптимизировать отдаваемые страницы - крайне имеет смысл рассмотреть модуль google_pagespeed - он есть и для Nginx, и для Apache. Этот модуль, кроме всего прочего, тоже умеет кэшировать данные, и при должной нагрузке весьма не плохо оптимизирует отдаю страниц и статики, а так же позволяет снизить нагрузку на сервер.

---------- Добавлено 25.04.2019 в 14:43 ----------

Не совсем так. Сама по себе проверка, есть ли страница в кэше и её отдача - выполняются с помощью PHP. В случае кэширования Nginx - ну, тут такое, что запрос до PHP может просто и не дойти. Зависит всё от подхода и от непосредственно задач.

На своём сайте экспериментировал - выбирал тип кэширования и мемкешед и файлы в настройках Битрикс (сервис мемкешед разумеется поднимал :) ) - так вот без мемкешед быстрее отдача страниц у меня была :)

Но памяти должно быть много чтобы файловый кэш эффективно работал.

# free -h

              total        used        free      shared  buff/cache   available

Mem:            62G        2,1G         34G        3,2G         25G         56G

Swap:            0B          0B          0B

suffix, Мемкешд он будет эффективен при большой нагрузке. Кроме того, там тоже много чего можно крутить. Просто поднять не достаточно. Ну и опять же, сам по себе мемкешд используют прежде всего потому, что он значительно предсказуемее и он управляем, в отличие от кэша ФС.

Это не объективно. Вы сравниваете адаптеры кеширования: файловый и memcached. Во-первых, в файлах имеет смысл хранить большие данные (т.к. диск априори больше по размеру), в оперативке - нет. В оперативке хранят что-то легкое, но часто запрашиваемое. Например, на диск можно закешировать sitemap, или какой-то прайс-лист, чтобы не формировать его на каждый запрос. В оперативку это писать смысла нету, оно отожрет много МБ, да и спрашивать будут пару раз в сутки, в оперативку лучше записать валюты, всякую пагинацию чтобы не делать COUNT(*) и прочее, что весит мало, а спрашиваеться часто. Я вообще не в зуб ногой в битриксе, но детали реализации могут отличаться (и должны, между дисковым кешем и оперативным).

Чтобы сравнивать файлы vs memcached - возьмите, напишите скриптик, и прогоните бенчмарком.

https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

P.S. Я прошел этапы, когда приходилось отказаться от базы, от файлов, от Redis (из-за сисколов), и написать свое хранилище In-Memory, пусть и без персистов, но выдающее около 60к рпс на 8 ядерной машине без каких либо напрягов.