Розуміння кешування в WordPress, частина 1
У травні я написав статтю про використання API WordPress Transients. Я резюмую статтю так:
Щоб імітувати файли cookie та їх функцію закінчення терміну дії, використання перехідних процесів WordPress може бути життєздатним рішенням.
https://wordpress.mediadoma.com/uk/vikoristannja-wordpress-transients-zamist-fajliv-cookie/
Хоча мета статті полягала в тому, щоб закласти основу для того, як ми можемо розробити клас для роботи з Transients API для моделювання поведінки файлів cookie, одним із побічних ефектів статті є те, що вона не виконала належної роботи пояснення того, як працює Transient API (і, через проксі, як працює MySQL).
Девід з UpDraft Plus звернув мою увагу на це електронною поштою .
Тож я вважав за доцільне поговорити про концепцію кешування з практичного рівня, про те, як це реалізовано у WordPress, потім, можливо, подивитись на те, як використовувати плагіни чи новішу технологію для кращої роботи наших сайтів і програм, а також мати краще розуміння.
Розуміння кешування: основи
Концепція кешування відносно проста. Але я думаю, що найкраще це продемонструвати, спершу поговоривши про серіалізацію та пошук даних без кешування.
Без кешування
Запис даних
Щоразу, коли ви записуєте інформацію в базову базу даних, ви записуєте запис або серію записів у базу даних.
Наприклад, коли ви публікуєте допис, ви збираєтеся записати запис до таблиці для дописів і таблиці для метаданих допису, кожна з яких пов’язана ідентифікатором допису.
Те, як вони пов’язані, для цієї публікації не важливо.
Натомість у цій частині слід розуміти, що коли дані записуються в базу даних, створюється принаймні один запис, якщо не кілька.
Читання даних
Коли відвідувач потрапляє на сайт, щоб прочитати цю конкретну публікацію, уся інформація для цієї публікації буде запитана з бази даних, подана до програми WordPress, а потім відображена на інтерфейсі.
Подумайте про весь цей процес як про подорож:
- ❓відвідувач запитує сторінку,
- 🔍 веб-сервер визначив, яку сторінку завантажити,
- 📂 сторінка запитується з бази даних із кількох таблиць,
- 🏗 дані збираються та надсилаються до основної програми,
- 🖥 дані представлені користувачеві.
Таким чином, подорож починається, коли користувач запитує сторінку, і закінчується, коли інформація відображається йому в браузері.
Це подорож
І без кешування це відбувається для кожного окремого користувача. Тобто для кожного користувача, який відвідує ваш сайт, потрібно зробити подорож.
Це може бути дуже дорогим з точки зору ресурсів і часу (особливо залежно від розміру вашої бази даних).
Але саме тут може вступити в гру кешування.
Перед початком кешування
Ідея кешування полягає в тому, щоб зробити весь цей процес швидшим. Тобто, якщо ми знаємо, що поїздка ось-ось відбудеться, ми можемо зберігати інформацію в такому місці, щоб вона була вже зібрана і її можна було швидше отримати.
Перш ніж говорити про це, про що я розповім у наступному дописі, зауважте, що це схоже на подорож до жорсткого диска сервера, на якому розміщено сайт, кожного разу, коли його відвідують.
Оскільки, зрештою, база даних, файли та всі ресурси, необхідні для роботи сайту, знаходяться на жорсткому диску. І так, такі речі, як твердотільні накопичувачі, можуть пришвидшити цей процес, але це все ще не настільки оптимально.
І тут на сцену з’являється кешування. Щоб краще зрозуміти Transients API, важливо розуміти кешування, яке спочатку вимагає базового розуміння того, як все працює без кешування.
Це Буквар
Тому вважайте це основним прикладом того, як працює сайт із базою даних без кешування. А потім ми розглянемо це в наступній публікації.