Italiano
Español
RomânăКак работает кэширование объектов?
Я ищу окончательный ответ на этот вопрос. Когда включено кэширование объектов, где в итоге хранятся опции и временные данные (transients)?
По умолчанию, и то и другое хранится в базе данных. Но я слышал упоминания о том, что Memcache хранит их где-то в другом месте, а APC делает что-то совершенно иное. Где именно эти данные будут сохраняться в обоих случаях?
придирка 1: Не все опции загружаются при старте страницы, а только те, которые помечены как "autoload=yes" при создании. Значение по умолчанию для этого параметра в add_option — 'yes', и большинство разработчиков плагинов не заморачиваются с пониманием разницы при использовании 'no', что делает ваше утверждение практически верным.
Mark Kaplun
Даже не автозагружаемые опции кэшируются после первого их получения. Они могут не загружаться изначально, но после этого попадают в кэш объектов. Даже несуществующие опции кэшируются! https://github.com/WordPress/WordPress/blob/master/wp-includes/option.php#L58-L71 Я добавил примечание о параметре autoload.
chrisguitarguy
это была придирка 2 ;)
Mark Kaplun
Спасибо за отличную статью и за время, потраченное на её обобщение.
prosti
Какая блестящая и полезная информация, спасибо!
And Finally
Знаю, что ответ довольно старый, но я бы также добавил отличный Redis.
Cranio
@Cranio, ты прав, но... Redis по сути является вариантом memcache с хранением данных, и поэтому это (NoSQL) база данных. На мой взгляд, это скорее недостаток, так как при отказе узла или невозможности его обновления можно получить устаревшую информацию. У него есть опция отключения режима базы данных, но я не уверен, включена она по умолчанию или нет.
Mark Kaplun
Это идеальная замена для Memcached (даже лучше), чего ещё нужно? Наиболее распространённый вариант использования, который я видел — это просто хранилище ключ-значение в оперативной памяти (да, помимо этого данные можно сделать персистентными, кластеризация в разработке, есть возможности управления очередями, но все добавляют Redis как отличный вариант кэширования для WP)
Cranio
каждый может также прыгнуть с моста ;) но дополнительная сложность абсолютно не нужна для кеширования
Mark Kaplun
Это совершенно бессмысленно; вам нужно кеширование в оперативной памяти, Redis делает кеширование в оперативной памяти, точка; и делает это прекрасно. Здесь абсолютно нет дополнительной сложности, если вы не хотите углубляться в это. Так что, сэр, я действительно не понимаю вашу точку зрения.
Cranio
Отличный вопрос.
Думаю, часть о том, как WordPress использует класс WP_Object_Cache, всё ещё отсутствует, поэтому я её добавлю.
Из документации:
ОПРЕДЕЛЕНИЕ: WordPress Object Cache используется для уменьшения количества обращений к базе данных. Объектный кеш сохраняет все данные кеша в памяти и делает их доступными с помощью ключа, который используется для именования и последующего извлечения содержимого кеша.
Вот структура WP_Object_Cache.
Примечание: + означает public, - private, # protected.
Вы можете использовать метод stats() для отображения общей статистики о глобальном объекте кеша и его содержимом. Вот пример вывода:
Cache Hits: 110
Cache Misses: 98
Group: options - ( 81.03k )
Group: default - ( 0.03k )
Group: users - ( 0.41k )
Group: userlogins - ( 0.03k )
Group: useremail - ( 0.04k )
Group: userslugs - ( 0.03k )
Group: user_meta - ( 3.92k )
Group: posts - ( 1.99k )
Group: terms - ( 1.76k )
Group: post_tag_relationships - ( 0.04k )
Group: category_relationships - ( 0.03k )
Group: post_format_relationships - ( 0.02k )
Group: post_meta - ( 0.36k )
Это то, что я получил в самом начале шаблона, например, single.php.
Обратите внимание на переменную, которая нас интересует:
global $wp_object_cache.
Приватный член $cache содержит сами данные кеширования.
В программировании структуры кеша встречаются повсеместно. В простейшей форме их можно представить как пары "ключ-значение". Бакеты, NoDB-структуры, индексы базы данных. Конечная цель WordPress Object Cache заключалась не в создании максимально простой структуры, но всё равно можно заметить пары "ключ-значение".
Поскольку я находился в single.php, когда выводил кеш:
print_r($wp_object_cache->cache['posts']);
Я получал закешированный одиночный пост.
[last_changed] => 0.34169600 1481802075
[get_page_by_path:2516f01e446b6c125493ec7824b63868:0.34169600 1481802075] => 0
[2831] => WP_Post Object
(
[ID] => 2831
[post_author] => 1
... здесь идёт закешированный объект поста
)
Объект будет значением, а ключ кеширования будет таким:
get_page_by_path:2516f01e446b6c125493ec7824b63868:0.34169600 1481802075
Здесь вы можете проверить структуру $cache_key:
Файл: /wp-includes/post.php
4210: /**
4211: * Получает страницу по её пути.
4212: *
4213: * @since 2.1.0
4214: *
4215: * @global wpdb $wpdb WordPress database abstraction object.
4216: *
4217: * @param string $page_path Путь страницы.
4218: * @param string $output Опционально. Требуемый тип возвращаемого значения. Один из OBJECT, ARRAY_A или ARRAY_N, что соответствует
4219: * объекту WP_Post, ассоциативному массиву или числовому массиву соответственно. По умолчанию OBJECT.
4220: * @param string|array $post_type Опционально. Тип записи или массив типов записей. По умолчанию 'page'.
4221: * @return WP_Post|array|null WP_Post (или массив) при успехе, или null при неудаче.
4222: */
4223: function get_page_by_path( $page_path, $output = OBJECT, $post_type = 'page' ) {
4224: global $wpdb;
4225:
4226: $last_changed = wp_cache_get_last_changed( 'posts' );
4227:
4228: $hash = md5( $page_path . serialize( $post_type ) );
4229: $cache_key = "get_page_by_path:$hash:$last_changed";
4230: $cached = wp_cache_get( $cache_key, 'posts' );
4231: if ( false !== $cached ) {
4232: // Особый случай: '0' - это некорректный `$page_path`.
4233: if ( '0' === $cached || 0 === $cached ) {
4234: return;
4235: } else {
4236: return get_post( $cached, $output );
4237: }
4238: }