WordPress domyślnie ma formę „buforowania obiektów”, ale jego żywotność to tylko ładowanie jednej strony.
Opcje są naprawdę dobrym tego przykładem. Sprawdź tę odpowiedź, aby uzyskać więcej informacji. Podsumowanie:
- Strona się zaczyna
- Wszystkie opcje są ładowane za pomocą prostego
SELECT option_name, option_value from $wpdb->options instrukcji
- Kolejne żądania tych opcji (np. Wezwanie do
get_optionnigdy nie trafienia do bazy danych, ponieważ są one przechowywane z API pamięci podręcznej WP).
Opcje zawsze znajdują się „na żywo” w bazie danych i zawsze są tam przechowywane - to jest ich „kanoniczne” źródło. To powiedziawszy, opcje są ładowane do pamięci podręcznej obiektów, więc kiedy poprosisz o opcję, istnieje 99% szans, że żądanie nigdy nie trafi do bazy danych.
Stany przejściowe są nieco inne.
WordPress pozwala zastąpić interfejs pamięci podręcznej drop-in - plik, który jest umieszczany bezpośrednio w wp-contentfolderze. Jeśli utworzysz własną pamięć podręczną, upuść lub użyj istniejącej wtyczki , możesz sprawić, że pamięć podręczna obiektów będzie utrzymywać się dłużej niż ładowanie pojedynczej strony. Kiedy to zrobisz, stany przejściowe, trochę się zmień.
Rzućmy okiem na set_transientfunkcję w 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;
}
Hmmm $_wp_using_ext_object_cache? Jeśli to prawda, WordPress zamiast tego używa pamięci podręcznej obiektów bazy danych do przechowywania stanów nieustalonych. Jak to się dzieje do prawdy? Czas zbadać, w jaki sposób WP konfiguruje własny interfejs API pamięci podręcznej.
Możesz prześledzić prawie wszystko do wp-load.phplub wp-settings.php- oba są kluczowe dla procesu ładowania WordPressa. W naszej pamięci podręcznej znajduje się kilka odpowiednich wierszy wp-settings.php.
// Start the WordPress object cache, or an external object cache if the drop-in is present.
wp_start_object_cache();
Pamiętasz ten spadek z góry? Rzućmy okiem na wp_start_object_cachew 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' ) );
}
}
Odpowiednie linie funkcji (odnoszące się do $_wp_using_ext_object_cachetego zmieniają sposób przechowywania stanów nieustalonych).
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;
}
jeśli object-cache.phpistnieje w twoim katalogu zawartości, zostaje dołączony i WP zakłada, że używasz zewnętrznej, trwałej pamięci podręcznej - ustawia się $_wp_using_ext_object_cachena true.
Jeśli korzystasz z zewnętrznego obiektu pamięci podręcznej, będą go używać transjenty. Co rodzi pytanie o to, kiedy należy używać opcji vs. stanów nieustalonych.
Prosty. Jeśli potrzebujesz danych, aby trwały bez końca, skorzystaj z opcji. Dostają „buforowane”, ale ich kanonicznymi źródłami jest baza danych i nigdy nie odejdą, chyba że użytkownik wyraźnie o to poprosi.
W przypadku danych, które powinny być przechowywane przez określony czas, ale nie muszą trwać dłużej niż określone przejściowe okresy użytkowania. Wewnętrznie WP spróbuje użyć zewnętrznej, trwałej pamięci podręcznej obiektów, jeśli będzie to możliwe, w przeciwnym razie dane przejdą do tabeli opcji i zostaną usunięte śmieci za pomocą psuedo-cron WordPressa po ich wygaśnięciu.
Niektóre inne obawy / pytania:
- Czy można wykonywać mnóstwo połączeń z
get_option? Prawdopodobnie. Powodują wywołanie funkcji narzutu funkcji, ale prawdopodobnie nie trafi ona do bazy danych. Ładowanie bazy danych jest często większym problemem w zakresie skalowalności aplikacji internetowych niż praca generowana przez wybrany język.
- Skąd mam wiedzieć, jak używać transjentów w porównaniu z API Cache? Jeśli oczekujesz, że dane będą się utrzymywać przez określony czas, użyj przejściowego interfejsu API. Jeśli nie ma znaczenia, czy dane będą się utrzymywać (np. Obliczenie / pobranie danych nie potrwa długo, ale nie powinno się to zdarzyć częściej niż raz na ładowanie strony), użyj interfejsu API pamięci podręcznej.
- Czy wszystkie opcje są naprawdę buforowane przy każdym ładowaniu strony? Niekoniecznie. Jeśli zadzwonisz
add_optionz ostatnim, opcjonalnym argumentem, ponieważ nonie są one automatycznie ładowane. To powiedziawszy, gdy raz je ściągniesz, przejdą do pamięci podręcznej, a kolejne połączenia nie trafią do bazy danych.
