Do-It-Yourself Кэширование Методы с WordPress

Но даже если вы используете такие плагины, использование внутренних методов кэширования для объектов и результатов базы данных является хорошей практикой разработки, так что ваш плагин не зависит от того, какие плагины кэша есть у конечного пользователя. Ваш плагин должен быть быстрым сам по себе, не в зависимости от других плагинов, чтобы сделать грязную работу. И если вы считаете, что вам нужно написать свой собственный код обработки кэша, вы ошибаетесь. WordPress поставляется со всем необходимым для быстрой реализации различной степени кэширования данных. Просто определите части кода, чтобы извлечь выгоду из оптимизации, и выберите тип кэширования.

Дальнейшее чтение на SmashingMag:

• Изменение админ пост списки в WordPress
• Полезные бесплатные плагины для WordPress
• Десять вещей, каждый WordPress Plugin Разработчик должен знать
• Внутри панели инструментов WordPress

WordPress реализует два различных метода кэширования:

1. Непостоянные Данные остаются в кэше во время загрузки страницы. (WordPress использует это для кэша большинства результатов запроса базы данных.)
2. Стойкий Это зависит от работы базы данных, и кэшированные данные могут автоматически истечь через некоторое время. (WordPress использует это для кэша RSS-каналов, проверки обновлений и т.д.)

Непостоянный кэш

При использовании таких функций, как get_posts() get_post_meta() или, WordPress первой проверки, чтобы увидеть, является ли данные, которые вы требуете кэшируется. Если это так, то вы получите данные из кэша; если нет, то для получения данных заработает запрос базы данных. После получения данных они также кэшированы. Непостоянный кэш рекомендуется для результатов базы данных, которые могут быть повторно использованы при создании страницы.

Код для внутреннего непостоянного кэша WordPress находится в cache.php файле в wp-includes каталоге и обрабатывается WP_Object_Cache классом. Нам нужно использовать две основные функции: wp_cache_set() wp_cache_get() и, наряду с дополнительными wp_cache_add() wp_cache_replace() функциями, wp_cache_flush() wp_cache_delete() и. Кэшированное хранение организовано в группы, и каждая запись нуждается в своем уникальном ключе. Чтобы избежать смешивания с данными WordPress по умолчанию, с помощью собственных уникальных имен групп лучше всего.

Примере

В этом примере мы создадим функцию под d4p_get_all_post_meta() названием , которая будет извлекать все метаданные, связанные с публикацией. Эта первая версия не предполагает кэширования.

function d4p_get_all_post_meta($post_id) {
    global $wpdb;

    $data = array();
    $raw = $wpdb->get_results( "SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id = $post_id", ARRAY_A );

    foreach ( $raw as $row ) {
        $data[$row['meta_key']][] = $row['meta_value'];
    }

    return $data;
}

Каждый раз, когда вы называете эту функцию для одного и того же идентификатора публикации, будет выполняться запрос S’L. Вот измененная функция, которая использует WordPress ‘непостоянный кэш:

function d4p_get_all_post_meta($post_id) {
    global $wpdb;

    if ( ! $data = wp_cache_get( $post_id, 'd4p_post_meta' ) ) {
        $data = array();
        $raw = $wpdb->get_results( "SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id = $post_id", ARRAY_A );

        foreach ( $raw as $row ) {
            $data[$row['meta_key']][] = $row['meta_value'];
        }

        wp_cache_add( $post_id, $data, 'd4p_post_meta' );
    }

    return $data;
}

Здесь мы используем группу кэша под d4p_post_meta названием, и post_id является ключом. С помощью этой функции мы сначала проверяем, нужны ли нам какие-либо данные из кэша (строка 4). Если нет, мы запускаем обычный код, чтобы получить данные, а затем добавить его в кэш в строке 13. Таким образом, если вы называете эту функцию более одного раза, только первый будет выполнять запросы S’L; все остальные вызовы будут получать данные из кэша. Мы используем wp_cache_add функцию здесь, так что если комбинация ключевых групп уже существует в магазине, она не будет заменена. Сравните это с wp_cache_set , который всегда будет перезаписать существующее значение без проверки.

Как вы можете видеть, мы внесли лишь небольшое изменение в существующий код, но потенциально сохранили много повторных вызовов базы данных во время загрузки страницы.

Важные заметки

1. Непостоянный кэш доступен только при загрузке текущей страницы; как только следующая страница загружается, она будет пустой еще раз.
2. Размер хранилища ограничен общей доступной памятью ДЛЯ PHP на сервере. Не храните большие наборы данных, или вы можете в конечном итоге с «Из памяти» сообщение.
3. Использование этого типа кэша имеет смысл только для операций, повторяющихся несколько раз при создании страницы.
4. Он работает с WordPress с версии 2.0.

Временно управляемый базой данных кэш

Этот тип кэша опирается на функцию, встроенную в WordPress называется Переходный API. Переходные данные хранятся в базе данных (по аналогии с большинством настроек WordPress, в wp_options таблице). Переходным требуется две записи в базе данных: одна для хранения времени истечения срока действия и одна для хранения данных. При запросе кэшированных данных WordPress проверяет метку времени и делает одну из двух вещей. Если срок действия прошел, WordPress удаляет данные и возвращает false в результате. Если срок действия данных не истек, для его извлечения занимательный запрос запускается другой запрос. Хорошая вещь об этом методе заключается в том, что кэш сохраняется даже после загрузки страницы, и он может быть использован для других страниц до тех пор, пока время истечения переходного не прошло.

Если запросы базы данных сложны и/или дают результаты, которые могут часто меняться не часто, то хранить их в переходном кэше — хорошая идея. Это отличное решение для большинства виджетов, меню и других элементов страницы.

Примере

Допустим, мы хотели, чтобы запрос на получение 20 сообщений за предыдущий месяц, а также некоторые основные данные автора, такие как имя, адрес электронной почты и URL- адрес. Но мы хотим, чтобы сообщения только из 10 лучших авторов (отсортированы по их общее количество сообщений в этом месяце). Результаты будут отображаться в виджете.

При тестировании на локальной машине этот запрос на S’L занял 0,1710 секунды. Если бы у нас было 1000 просмотров страниц в день, этот запрос занимал бы 171 секундкаждый 24 часа, или 5130 секунд в месяц. Относительно говоря, это не так много времени, но мы могли бы сделать гораздо лучше, используя переходный кэш для хранения этих результатов с истечением времени 30 дней. Поскольку результаты этого запроса не изменятся в течение месяца, переходный кэш — это отличный способ оптимизации ресурсов.

Возвращаясь к локальной машине, улучшенный запрос S’L для получения данных из переходного кэша теперь составляет всего 0,0006 секунды, или 18 секунд в месяц. Преимущество этого метода очевидно в этом случае: мы сохранили 85 минут каждый месяц с этим один виджет. Совсем неплохо. Есть случаи, в которых вы могли бы сэкономить гораздо, гораздо больше (например, с очень сложнымменю). Более сложные запросы или операции s’L будут способствовать дальнейшей оптимизации ресурсов.

Рассмотрим фактический код как до, так и после реализации переходного кэша. Ниже приведена нормальная функция для получения данных. В этом примере запрос S’L пуст (потому что он длинный и займет слишком много места здесь), но весь виджет связан с в конце этой статьи.

function d4p_get_query_results() {
    global $wpdb;

    $data = $wpdb->get_results(' // SQL query // ');

    return $data;
}

А вот функция с использованием переходного кэша, с несколькими дополнительными строками, чтобы проверить, являются ли данные кэшированы.

function d4p_get_query_results() {
    global $wpdb;

    $data = get_transient('my_transient_key');

    if ($data === false) {
        $data = $wpdb->get_results(' // SQL query // ');
        set_transient('my_transient_key', $data, 3600 * 24);
    }

    return $data;
}

Функция get_transient (или get_site_transient для сети) нуждается в имени для переходного ключа записи. Если ключ не найден или запись истекла, то функция false вернется. Чтобы добавить новую преходящую запись кэша, вам понадобится ключ записи, объект с данными и время истечения (в секундах), и вам нужно будет использовать set_transient функцию (или set_site_transient для сети).

Если данные изменяются, их можно удалить из кэша. Вам понадобится ключ записи и delete_transient функция (или delete_site_transient для сети). В этом примере, если публикация в кэше удалена или изменена каким-либо образом, можно удалить запись кэша с помощью этого:

delete_transient('my_transient_key');

Важные заметки

1. Теоретический максимальный размер данных, которые можно хранить таким образом, составляет 4 ГБ. Но обычно вы будете держать гораздо меньшие объемы данных в переходных (до нескольких МБ).
2. Используйте этот метод только для данных (или операций), которые не часто меняются, и установите время истечения, чтобы соответствовать циклу изменений данных.
3. По сути, вы используете его для визуализации результатов, которые генерируются через ряд запросов базы данных и хранения полученного HTML в кэше.
4. Имя переходной записи не может быть длиннее 45 символов, или 40 символов для «переходных сайтов» (используется с несколькими сайтами для хранения данных на сетевом уровне).
5. Он работает с WordPress с версии 3.0.

Пример виджета: Использование обоих типов кэша

Основываясь на нашем запросе s’L, мы можем создать виджет, который опирается на оба метода кэширования. Это два подхода к проблеме, и два виджета будут производить по существу один и тот же выход, но с использованием различных методов для поиска данных и кэширования результатов. Как администратор, можно установить заголовок для виджета и количество дней, чтобы сохранить результаты в кэше.

Обе версии просты и могут быть улучшены далее (например, путем выбора типа поста или путем форматирования вывода), но для этой статьи их достаточно.

Сырье виджет

В «сырой» версии виджета сохраняется объект, при этом запрос S’L приводит к переходным кэшу. В этом случае запрос S’L возвращает все столбцы из wp_posts таблицы и некоторые столбцы из wp_users таблицы, а также информацию об авторах. Каждый раз, когда виджет загружается, каждый пост из нашего набора результатов будет храниться в непостоянном объекте кэша в стандартной posts группе, которая является той же, используемой для хранения сообщений для обычных операций WordPress. Из-за этого такие функции, как get_permalink() может использовать кэшированный объект для создания URL-адреса для публикации. Информация об авторах из wp_users таблицы используется для создания URL-адреса для архива авторских постов.

Этот виджет находится в method_raw.php файле в d4p_sa_method_raw классе. Функция get_data() является наиболее важной частью виджета. Он пытается получить данные из переходного кэша (на линии 52). В противном случае get_data_real() требуется выполнить запрос s’L и вернуть данные. Теперь эти данные сохраняются в переходном кэше (строка 56). После того, как у нас есть данные, мы храним каждый пост из набора в непостоянный кэш. renderФункция проста; она отображает результаты как неупорядоченный список.

Оказанный виджет

Предыдущий метод работает хорошо, но он может иметь одну проблему. Что делать, если ваша постоянная информация зависит от категорий (или других таксономий) или вы запустите запрос для типа публикации в иерархии? Если это так, то генерация пермалинки для каждой публикации потребует дополнительных запросов на S-L. Например, для отображения 20 сообщений может потребоваться еще 20 или более запросов. Чтобы устранить проблему, мы изменим способ получения данных и то, что хранится в переходном кэше.

Второй виджет находится в method_rendered.php файле в d4p_sa_method_rendered классе. Внутри, имена методов класса одинаковы, так что теперь вы можете легко увидеть разницу между двумя виджетами. В этом случае в методе используется переходный render() кэш. Мы проверяем кэшированные данные, и если это не удается, мы используем get_data() для получения набора данных и создания визуализированного списка результатов. Теперь мы кэширования отрисованного HTML вывода! Независимо от того, сколько дополнительных запросов S’L необходимо для создания HTML (для постоянных ссылок или что-нибудь еще, что вам может понадобиться в виджете), они выполняются только один раз, и полный HTML кэшируется. До истечения срока действия кэша мы всегда отображаем HTML, отображаемый без необходимости в дополнительных запросах или обработке.

Скачать виджет

Вы можете скачать этот D4P Smashing Авторы плагин, который содержит оба виджета.

Заключение

Как вы можете видеть, реализация одного или обоих методов кэширования легко и может значительно улучшить производительность вашего плагина. Если пользователь вашего плагина решает использовать специализированный плагин кэширования, тем лучше, но убедитесь, что ваш код оптимизирован.