Еще в мае я написал статью об использовании WordPress Transients API. Резюмирую статью так:
Для имитации файлов cookie и их функции истечения срока действия использование переходных процессов WordPress может быть жизнеспособным решением.
https://wordpress.mediadoma.com/ru/ispolzovanie-wordpress-transients-vmesto-fajlov-cookie/
Хотя цель статьи состояла в том, чтобы заложить основу того, как мы можем разработать класс для работы с Transients API для имитации поведения файлов cookie, одним из побочных эффектов статьи является то, что она не справилась со своей задачей. объяснить, как работает Transients API (и, по доверенности, как MySQL).
Это было доведено до моего сведения по электронной почте Дэвидом из UpDraft Plus.
Поэтому я подумал, что было бы полезно поговорить о концепции кэширования с практической точки зрения, о том, как она реализована в WordPress, а затем, возможно, рассмотреть, как использовать плагины или новые технологии для повышения эффективности наших сайтов и приложений, а также для лучшего понимания.
Понимание кэширования: основы
Концепция кэширования относительно проста. Но я думаю, что лучше всего это продемонстрировать, поговорив сначала о сериализации и извлечении данных без кэширования.
Без кэширования
Запись данных
Всякий раз, когда вы записываете информацию в основную базу данных, вы записываете запись или ряд записей в базу данных.
Например, когда вы публикуете сообщение, вы будете записывать запись в таблицу для сообщений и таблицу для метаданных сообщений, каждая из которых связана идентификатором сообщения.
Как они связаны, не важно для этого поста.
Вместо этого в этой части нужно понимать, что когда данные записываются в базу данных, создается по крайней мере одна запись, если не несколько.
Чтение данных
Когда посетитель попадает на сайт, чтобы прочитать этот конкретный пост, вся информация для указанного поста будет запрашиваться из базы данных, передаваться в приложение WordPress, а затем отображаться во внешнем интерфейсе.
Думайте обо всем этом процессе как о путешествии:
- ❓ посетитель запрашивает страницу,
- 🔍 веб-сервер определил, какую страницу загружать,
- 📂 страница запрашивается из базы данных из нескольких таблиц,
- 🏗 данные собираются и отправляются в основное приложение,
- 🖥 данные представлены пользователю.
Таким образом, путешествие начинается, когда пользователь запрашивает страницу, и заканчивается, когда информация предоставляется ему в браузере.
это путешествие
И без кэширования это происходит для каждого отдельного пользователя. То есть для каждого пользователя, зашедшего на ваш сайт, должна быть совершена поездка.
Это может быть очень дорого с точки зрения ресурсов и времени (особенно в зависимости от размера вашей базы данных).
Но здесь может вступить в игру кэширование.
Прежде чем приступить к кэшированию
Идея кэширования состоит в том, чтобы ускорить весь этот процесс. То есть, если мы знаем, что путешествие вот-вот произойдет, мы можем хранить информацию в таком месте, чтобы она уже была собрана и ее можно было быстрее получить.
Прежде чем говорить об этом, о чем я расскажу в следующем посте, обратите внимание, что это похоже на путешествие к жесткому диску сервера, на котором размещен сайт, каждый раз, когда сайт посещают.
Потому что, в конечном счете, база данных, файлы и все активы, необходимые для работы сайта, находятся на жестком диске. И да, такие вещи, как твердотельные накопители, могут ускорить этот процесс, но он все еще не настолько оптимален, насколько это возможно.
И вот тут на сцену выходит кэширование. Чтобы лучше понять Transients API, важно понимать кэширование, что в первую очередь требует базового понимания того, как все работает без кэширования.
это учебник
Так что считайте это базовым пособием по тому, как работает сайт с базой данных без кэширования. И затем мы будем опираться на это больше в следующем посте.