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? Вероятно. Они вызывают вызов функции, но, скорее всего, не попадут в базу данных. Загрузка базы данных часто является более серьезной проблемой в масштабируемости веб-приложений, чем работа, которую ваш язык делает для создания страницы.
- Как я знаю, чтобы использовать переходные процессы по сравнению с Cache API? Если вы ожидаете, что данные сохранятся в течение заданного периода, используйте переходный API. Если не имеет значения, сохраняются ли данные (например, это не займет много времени для вычисления / извлечения данных, но это не должно происходить более одного раза за загрузку страницы), используйте API-интерфейс кэширования.
- Все ли параметры действительно кэшируются при каждой загрузке страницы? Не обязательно. Если вы вызываете
add_optionс последним необязательным аргументом, поскольку noони не загружаются автоматически. Тем не менее, как только вы получите их один раз, они попадут в кеш, и последующие вызовы не попадут в базу данных.
