WordPress за замовчуванням виконує форму "Кешування об'єктів", але термін його експлуатації - це лише завантаження однієї сторінки.
Варіанти насправді є дуже хорошим прикладом цього. Ознайомтеся з цією відповіддю для отримання додаткової інформації. Підсумок:
- Починається сторінка
- Усі параметри завантажуються простим
SELECT option_name, option_value from $wpdb->optionsтвердженням
- Подальші запити на ці параметри (наприклад, заклик
get_optionніколи не потрапляти в базу даних, оскільки вони зберігаються з API кешу WP.
Опції завжди "живуть" в базі даних і завжди зберігаються там - ось їх "канонічне" джерело. Однак, параметри завантажуються в кеш об'єктів, тому при запиті опції є 99% шансу, що запит ніколи не потрапить до бази даних.
Тимчасові трохи відрізняються.
WordPress дозволяє замінити кеш-api на випадаючий - файл, який розміщується безпосередньо у вашій wp-contentпапці. Якщо ви створюєте власний папір кешу або використовуєте наявний плагін , ви можете змусити об’єкт кеш зберігатись довше, ніж завантаження однієї сторінки. Коли ви це зробите, тимчасові зміни трохи змініть.
Давайте розглянемо set_transientфункцію в wp-includes/option.php.
<?php
/**
* Set/update the value of a transient.
*
* You do not need to serialize values. If the value needs to be serialized, then
* it will be serialized before it is set.
*
* @since 2.8.0
* @package WordPress
* @subpackage Transient
*
* @uses apply_filters() Calls 'pre_set_transient_$transient' hook to allow overwriting the
* transient value to be stored.
* @uses do_action() Calls 'set_transient_$transient' and 'setted_transient' hooks on success.
*
* @param string $transient Transient name. Expected to not be SQL-escaped.
* @param mixed $value Transient value. Expected to not be SQL-escaped.
* @param int $expiration Time until expiration in seconds, default 0
* @return bool False if value was not set and true if value was set.
*/
function set_transient( $transient, $value, $expiration = 0 ) {
global $_wp_using_ext_object_cache;
$value = apply_filters( 'pre_set_transient_' . $transient, $value );
if ( $_wp_using_ext_object_cache ) {
$result = wp_cache_set( $transient, $value, 'transient', $expiration );
} else {
$transient_timeout = '_transient_timeout_' . $transient;
$transient = '_transient_' . $transient;
if ( false === get_option( $transient ) ) {
$autoload = 'yes';
if ( $expiration ) {
$autoload = 'no';
add_option( $transient_timeout, time() + $expiration, '', 'no' );
}
$result = add_option( $transient, $value, '', $autoload );
} else {
if ( $expiration )
update_option( $transient_timeout, time() + $expiration );
$result = update_option( $transient, $value );
}
}
if ( $result ) {
do_action( 'set_transient_' . $transient );
do_action( 'setted_transient', $transient );
}
return $result;
}
Хммм $_wp_using_ext_object_cache? Якщо це правда, WordPress використовує об’єктний кеш замість бази даних для зберігання перехідних процесів. Отже, як це встановити до істини? Час вивчити, як WP налаштовує власний API кешу.
Ви можете простежити майже все wp-load.phpабо wp-settings.php- і те, і інше - вирішальне значення для процесу завантаження WordPress. У нашому кеші є деякі відповідні рядки в wp-settings.php.
// Start the WordPress object cache, or an external object cache if the drop-in is present.
wp_start_object_cache();
Пам'ятаєте ту краплю речі вгорі? Давайте розглянемо wp_start_object_cacheв wp-includes/load.php.
<?php
/**
* Starts the WordPress object cache.
*
* If an object-cache.php file exists in the wp-content directory,
* it uses that drop-in as an external object cache.
*
* @access private
* @since 3.0.0
*/
function wp_start_object_cache() {
global $_wp_using_ext_object_cache, $blog_id;
$first_init = false;
if ( ! function_exists( 'wp_cache_init' ) ) {
if ( file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
require_once ( WP_CONTENT_DIR . '/object-cache.php' );
$_wp_using_ext_object_cache = true;
} else {
require_once ( ABSPATH . WPINC . '/cache.php' );
$_wp_using_ext_object_cache = false;
}
$first_init = true;
} else if ( !$_wp_using_ext_object_cache && file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
// Sometimes advanced-cache.php can load object-cache.php before it is loaded here.
// This breaks the function_exists check above and can result in $_wp_using_ext_object_cache
// being set incorrectly. Double check if an external cache exists.
$_wp_using_ext_object_cache = true;
}
// If cache supports reset, reset instead of init if already initialized.
// Reset signals to the cache that global IDs have changed and it may need to update keys
// and cleanup caches.
if ( ! $first_init && function_exists( 'wp_cache_switch_to_blog' ) )
wp_cache_switch_to_blog( $blog_id );
else
wp_cache_init();
if ( function_exists( 'wp_cache_add_global_groups' ) ) {
wp_cache_add_global_groups( array( 'users', 'userlogins', 'usermeta', 'user_meta', 'site-transient', 'site-options', 'site-lookup', 'blog-lookup', 'blog-details', 'rss', 'global-posts', 'blog-id-cache' ) );
wp_cache_add_non_persistent_groups( array( 'comment', 'counts', 'plugins' ) );
}
}
Відповідні рядки функції (ті, які стосуються $_wp_using_ext_object_cacheцього, змінюють спосіб зберігання перехідних процесів).
if ( file_exists( WP_CONTENT_DIR . '/object-cache.php' ) ) {
require_once ( WP_CONTENT_DIR . '/object-cache.php' );
$_wp_using_ext_object_cache = true;
} else {
require_once ( ABSPATH . WPINC . '/cache.php' );
$_wp_using_ext_object_cache = false;
}
якщо він object-cache.phpє у вашому каталозі вмісту, він включається, і WP припускає, що ви використовуєте зовнішній, стійкий кеш - він встановлює $_wp_using_ext_object_cacheзначення true.
Якщо ви використовуєте зовнішній об'єкт кеш-пам'яті, тимчасові кеші будуть використовувати його. Звідси виникає питання про те, коли використовувати опції проти перехідних.
Простий. Якщо вам потрібні дані для збереження на невизначений термін, використовуйте параметри. Вони отримують "кешування", але їхні канонічні джерела - це база даних, і вони ніколи не зникнуть, якщо користувач прямо не попросить цього.
Для даних, які слід зберігати протягом встановленого періоду часу, але не потрібно зберігати понад визначений час використання перехідних процесів. Внутрішньо WP спробує використовувати зовнішній, стійкий кеш об'єктів, якщо в іншому випадку дані перейдуть в таблицю параметрів і отримають сміття, зібране через psuedo-cron WordPress, коли вони закінчуються.
Деякі інші проблеми / питання:
- Чи добре робити тону дзвінків
get_option? Мабуть. Вони виконують виклик до накладних функцій, але це, швидше за все, не потрапить у базу даних. Завантаження баз даних часто викликає велике занепокоєння у масштабованості веб-додатків, ніж робота, якою вибираєте мову, для створення сторінки.
- Як я можу використовувати перехідні програми та API кешу? Якщо ви очікуєте, що дані зберігатимуться протягом встановленого періоду, використовуйте перехідний API. Якщо не важливо, чи зберігаються дані (наприклад, для обчислення / отримання даних не потрібно багато часу, але це не повинно відбуватися більше одного разу на завантаження сторінки), використовуйте API кешу.
- Чи дійсно всі параметри кешовано на кожному завантаженні сторінки? Не обов'язково. Якщо ви телефонуєте
add_optionз останнім, необов'язковим аргументом, оскільки noвони не завантажуються автоматично. Однак, як тільки ви їх отримаєте один раз, вони входять у кеш і наступні дзвінки не потраплять до бази даних.
