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


Да, этот запрос кэшироваться не будет, но будут кэшироваться все запросы к этой таблице, если их количество больше одного.
Это просто уменьшит вымывание кэша и, соответвенно, увеличит шансы на попадание в кэш результатов других запросов, независимо от того, обращаются они к этой же таблице или к какой-то другой.
Думаю параметр «innodb_buffer_pool_size» достоин упоминания, как особенно сильно влияющий на кэширование InnoDB таблиц.
Поддержу: почему написано только про PHP и MySQL?
Пост был бы интереснее, если бы обзор был бы шире.
Еще про кеширование на уровне service worker можно упомянуть. Весьма полезная вещь!
Кэширование страницы целиком

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

— APC;

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

2.4, 2.5

Не понял :)

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Если мы говорим о кешировании на бэкенде то это целиком и полностью зависит от бизнес логики вашего приложения/сайта. Начиная с того что кеширование вам вообще может не понадобиться (в случае если у вас микробложик с mongo в качестве базы данных) и заканчивая тем что вам может понадобиться ряд кеширующих upstream серверов с помощью которых будет балансироваться нагрузка.
Only those users with full accounts are able to leave comments. Log in, please.