11 видов кэширования для современного сайта

[miksoft]

В контексте MySQL еще остались неупомянутыми:

• Кэш индексов MyISAM
• Кэш индексов и таблиц InnoDB
• Кэш файловой системы как применительно к таблицам MyISAM, так и файлам вообще

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

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

[rouslanzs]

Думаю параметр «innodb_buffer_pool_size» достоин упоминания, как особенно сильно влияющий на кэширование InnoDB таблиц.

[miksoft]

Это и есть «Кэш индексов и таблиц InnoDB».

[xmaster83]

Лучше бы про Django, RoR, Sping, а то это жуткий баян.

[torrie]

Принципы те же, инструменты другие.

[Lure_of_Chaos]

Поддержу: почему написано только про PHP и MySQL?
Пост был бы интереснее, если бы обзор был бы шире.

[Gorky]

Потому что PHP и MySQL это лучшее что есть у веба )

[jbubsk]

Еще про кеширование на уровне service worker можно упомянуть. Весьма полезная вещь!

[M-A-XG]

Кэширование страницы целиком

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

— APC;

Уже актуален OpCache

2.4, 2.5

Не понял :)

2.6 Кэширование mysql на основе query cache

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

[miksoft]

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

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

А вот настоящий минус, имхо, в том, что он это удаление делает весьма долго. Из-за этого нет смысла делать его большого размера, т.к. накладные расходы на его содержание начинают превышать выгоды. По моим наблюдениям верхний порог находится где-то в районе 128-256 Мбайт.

[POPSuL]

нужно сбрасывать весь кеш

Ну, есть же теги. Инвалидируем по тегу некую группу данных и всё. Абсолютно весь кэш дропать не нужно.

[M-A-XG]

блок на всех страницах -> тег на всех страницах -> сбрасываем кеш тега -> сбрасываем весь кеш
:)

[POPSuL]

А… Ну да, не подумал об этом.
Из-за похожей проблемы (можно закэшировать всю страницу, но баннеры кэшировать нельзя) мне пришлось у себя сделать небольшой костыль:

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

Вообще, такую задачу вроде как можно с помощью varnish решить, но мне было лень разбираться :)

[franzose]

В Varnish есть ESI-разметка, делает ровно то же самое.

[miksoft]

Проще говоря,

WHERE show_ts<=UNIX_TIMESTAMP()

Если использовать постоянно меняющийся timestamp в таких запросах, то sql кэш будет не только бесполезен, но даже вреден, так как будет копиться количество кэшированных запросов, данные которых устарели в момент создания кэша.

Не будет.
How the Query Cache Operates

A query cannot be cached if it contains any of the functions shown in the following table.
…
UNIX_TIMESTAMP() with no parameter

[renskiy]

Плюс за разъяснение необходимости кэширования. Но хотелось бы увидеть в статье больше пояснений и ссылок на спецификации.

1.2 Кэширование https

Например, этот пункт для меня остался непонятным.

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

А для этого случая есть формализованные рекомендации в RFC7234, упоминание которого, кстати, в контексте статьи было бы очень уместным.

[pae174]

Не упомянуто кэширование ответов DNS на клиенте.

[Undiabler]

Смешались в кучу кони, люди…

Если мы говорим о кешировании со стороны юзера то тут важна оптимизация и буферизация доставляемого контента: http2, etag, localstorage, даже попадались извращения по типу хранения части данных в куках. Все это не упомянуто. Что уже говорить о современных вариантах по типу хромовского service worker.

Если мы говорим о кешировании на бэкенде то это целиком и полностью зависит от бизнес логики вашего приложения/сайта. Начиная с того что кеширование вам вообще может не понадобиться (в случае если у вас микробложик с mongo в качестве базы данных) и заканчивая тем что вам может понадобиться ряд кеширующих upstream серверов с помощью которых будет балансироваться нагрузка.