Розуміння кешування в WordPress, частина 3
У попередніх двох публікаціях я говорив про основи кешування та про те, як кешування працює в WordPress, принаймні певною мірою.
Але пам’ятайте, що ця серія була мотивована електронним листом від когось, хто вважав, що я зможу краще пояснити, як працюють перехідні процеси та кешування в WordPress і чому важливо розуміти, як усе працює в тандемі одне з одним.
Тож у цій публікації я збираюся об’єднати все це разом і поговорити про те, як Transients API працює разом із MySQL, чому важливо розуміти зв’язок і як з цим працювати далі.
Як перехідні процеси працюють у WordPress?
Як працюють перехідні процеси
По-перше, згідно з Кодексом, перехідні процеси працюють так:
Ця сторінка містить технічну документацію WordPress Transients API, яка пропонує простий і стандартизований спосіб тимчасового зберігання кешованих даних у базі даних, надаючи їм спеціальне ім’я та часовий проміжок, після якого вони закінчаться та будуть видалені.
Ідея цього здається досить простою, чи не так?
- Ви зберігаєте опцію в базі даних,
- Встановіть час, протягом якого він має існувати,
- Потім він зберігається протягом цього часу
- І, за запитом після закінчення терміну дії, він отримується та повертається у свій тимчасовий стан.
Тож де плутанина?
Як згадувалося в першій публікації, я не знав, як довго тимчасова інформація буде доступною. Це не мінімальний проміжок часу, протягом якого дані будуть доступні, це максимальний.
Це означає, що якщо ви встановили, що щось буде доступним протягом дня, воно буде доступним протягом дня. Не менше; не більше. А після закінчення цього часу його потрібно буде знову відтворити в перехідний стан.
Принаймні, це загальноприйнята думка. Це не неправильно, але в цьому є щось більше. Але це дещо більш технічно.
Яку роль відіграє MySQL?
У міру розвитку WordPress, хостингу та інших технологій базові бази даних, що забезпечують роботу програми, також змінилися. Це не добре чи погано (хоча, можливо, ми могли б сперечатися, що це добре в наступній публікації).
Але це може допомогти пояснити, чому перехідні процеси працюють так, як вони працюють, враховуючи стек, з яким ми звикли працювати, і чому вони можуть не працювати належним чином із нашими системами баз даних.
Якщо ви вирішите використовувати MySQL як базу даних для вашої інсталяції WordPress, я ризикну сказати, що більшість людей все ще робить, тоді інформація, яка міститься в таблиці Options (де також зберігаються перехідні процеси), тоді Transients API працюватиме як описані вище.
Але що станеться, якщо ви запровадите інші форми кешування, такі як кешування об’єктів, за допомогою такого програмного забезпечення, як Memcached або Redis тощо?
У такому випадку дані можуть бути недоступними, як ви очікуєте. Коротше кажучи, програмне забезпечення для кешування може видаляти інформацію, яка запитується не так часто, як інша інформація. Тобто він надає пріоритет інформації, яка запитується частіше.
Рухатися вперед
Коли ви берете до уваги все вищесказане, ви дивитесь на кілька речей:
- API Transients,
- база даних,
- стороння система кешування.
Коли у вас є Transients API і стандартна база даних, у вас все буде добре, оскільки все працюватиме так, як ви очікуєте.
Але якщо ви запровадите систему кешування третьої сторони, результат може бути іншим. Зокрема, речі можуть працювати не так, як ви очікуєте.
Тобто система кешування третьої сторони може ігнорувати будь-яку інформацію, яку вона хоче скинути, коли вважає за потрібне її видалити. Це означає, що все, що, на вашу думку, може бути доступним у кеші, там не буде.
Зрештою, найкраща порада, яку я можу дати:
- Якщо ви використовуєте MySQL і Transients API, все працюватиме, як описано в Codex.
- З іншого боку, якщо ви використовуєте іншу систему кешування, то важливо розуміти, як вона працює і як ви можете написати код на її основі, щоб вона працювала так, як вам хочеться.
І при цьому більше нічого додати до цього посібника для розуміння кешування в WordPress.